باعتباره أحد مبادئ التصميم الأساسية للبيتكوين، كان نموذج UTXO نموذجًا تقنيًا مهمًا في مجال blockchain منذ بدايته. فهو يلعب دورًا حاسمًا في ضمان أمان المعاملات وإمكانية تتبعها، مما يوفر مسارًا بديلاً يتجاوز نموذج رصيد الحساب التقليدي. مع التطور والتوسع المستمر لتقنية blockchain في السنوات الأخيرة، شهد نموذج UTXO نفسه تطورًا وامتدادًا مستمرًا، مثل eUTXO، والخلية، وقائمة الوصول الصارمة، وغيرها.

تقدم هذه المقالة نموذج UTXO بلغة واضحة، وتقدم نظرة عامة موجزة عن نموذج UTXO وطرق تنفيذ BTC وSui وCardano وNervos وFuel.

ما هو UTXO؟

لتوضيح نموذج UTXO نستخدم مثالاً:

تخيل شخصين، أليس وبوب، يمتلك كل منهما في البداية 5 دولارات. بعد ذلك، نشأ صراع، وسرق بوب مبلغ 2 دولار من أليس. والممتلكات النهائية لكل منها هي كما يلي:

من الواضح أن أليس حصلت في النهاية على 3 دولارات، بينما حصل بوب في النهاية على 7 دولارات. تُرى هذه الطريقة المحاسبية الشبيهة بالحساب الأولي بشكل شائع في الأنظمة المصرفية ويشار إليها باسم "نموذج الحساب/الرصيد". في هذا النموذج، يوجد رصيد الحساب كقيمة رقمية واحدة.

إذا أردنا اعتماد نهج مختلف عن نموذج الحساب، مثل استخدام UTXO لتمثيل نقل الثروة بين أليس وبوب، فإن الرسم البياني التوضيحي سيتخذ مظهرًا مختلفًا:

في هذه المرحلة، لا يزال لدى أليس 3 دولارات، ولا يزال لدى بوب 7 دولارات، لكن هذه الدولارات السبعة لا يتم تمثيلها بقيمة عددية واحدة. وبدلاً من ذلك، تم تقسيمها إلى "5 دولارات" و"2 دولار". هل يبدو هذا النهج غير التقليدي غير مألوف إلى حد ما؟ هذه هي الطريقة المحاسبية الفريدة المعروفة باسم UTXO.

يشير الاختصار الإنجليزي UTXO إلى مخرجات المعاملات غير المنفقة. بموجب هذا النهج المحاسبي، تظهر كل معاملة على السلسلة كتغييرات وتحويلات في UTXOs. على سبيل المثال، في حدث المعاملة المذكورة، تعمل "5$" التي تملكها أليس في البداية كمعلمات إدخال، تحمل علامة UTXO_0، والتي سيتم وضع علامة عليها كمنفقة؛ في الوقت نفسه، يقوم النظام بإنشاء "$2" (UTXO_1) و"$3" (UTXO_2) كمعلمات إخراج. سيتم نقل UTXO_1 إلى Bob، وسيتم إرجاع UTXO_2 إلى Alice، وبذلك يكتمل نقل الثروة بين Alice وBob.

في نموذج UTXO، لا توجد مفاهيم واضحة لـ "الحسابات" و"الأرصدة". تعمل UTXO كبنية بيانات تساعد في تنفيذ المعاملات، وتسجيل المعلومات مثل المبلغ الذي تمثله وفهرس المعاملات المرتبط به. يمثل كل UTXO مدخلات معاملة غير منفقة، مع مالك معين. عند حدوث معاملة، يمكن استخدام UTXOs معينة كمدخلات، وعند تدميرها، يتم إنشاء UTXOs جديدة كمخرجات للمعاملة.

هذه هي الطريقة التي تحتفظ بها Bitcoin بالحسابات: مع كل معاملة، يتم تدمير UTXOs القديمة وإنشاء أخرى جديدة. المبلغ الإجمالي لـ UTXOs المدمرة يساوي مبلغ UTXOs الذي تم إنشاؤه حديثًا (مع جزء مخصص كرسوم معاملات لعمال المناجم). وهذا يضمن عدم إمكانية زيادة الأموال بشكل تعسفي.

مقارنة بين نموذج UTXO ونموذج الحساب/الرصيد

لنفترض أن مجموعة من المستخدمين تبدأ عددًا كبيرًا من طلبات المعاملات في وقت واحد. كيف سيتم التعامل مع الموقف باستخدام نموذج UTXO مقارنة بنموذج الحساب/الرصيد؟

في نموذج الحساب/الرصيد، يكون لكل مستخدم حساب يحتوي على معلومات الرصيد المسجلة. عند حدوث معاملة، يجب تحديث رصيد الحساب المقابل، بما في ذلك عمليتي "القراءة" و"الكتابة". ومع ذلك، إذا كانت هناك معاملتان تتضمنان نفس الحساب، فغالبًا ما يؤدي ذلك إلى تعارضات القراءة والكتابة، مما يؤدي إلى خلاف الدولة، وهو موقف يجب تجنبه.

عادةً ما تعالج أنظمة قواعد البيانات التقليدية التنافس على القراءة والكتابة باستخدام آلية "القفل". في مثل هذا السيناريو، غالبًا ما تحتاج المعاملات التي تسبب التنافس على نفس البيانات إلى الوقوف في قائمة الانتظار، مما يمنع التنفيذ المتزامن ويقلل من كفاءة معالجة المعاملات. عندما يكون هناك عدد كبير من المعاملات التي تنتظر المعالجة، يمكن أن يؤدي ذلك إلى اختناقات كبيرة في الأداء، حيث تواجه المعاملات المتنازع عليها أوقات انتظار طويلة دون معالجة سريعة.

وعلى النقيض من نموذج رصيد الحساب، فإن نموذج UTXO الخاص بـ Bitcoin مجهز بشكل أفضل للتعامل مع مشكلات تنافس البيانات. في هذا النهج، لم يعد كيان المعالجة المباشرة لكل معاملة "حسابًا" محددًا بل أصبح UTXOs فرديًا ومستقلًا. نظرًا لأن UTXOs المختلفة لا تتداخل مع بعضها البعض، فإن كل معاملة في شبكة Bitcoin تعمل بشكل مستقل. ونتيجة لذلك، يمكن لعقد شبكة البيتكوين معالجة معاملات متعددة في وقت واحد دون الحاجة إلى "الأقفال"، مما يؤدي إلى تحسين إنتاجية النظام وأداء التزامن بشكل كبير.

بالإضافة إلى ذلك، في نموذج UTXO، تقوم المحافظ المشفرة عادةً بإنشاء عنوان جديد للمستخدم بعد بدء المعاملة. يعزز هذا النهج الخصوصية، مما يزيد من صعوبة ربط المعاملة بفرد معين. في المقابل، فإن نموذج الحساب/الرصيد، الذي يستخدم العناوين الثابتة، يكون أكثر عرضة لتحليل الارتباط.

ومع ذلك، فإن نموذج UTXO له حدوده. وقد تم تصميمه في البداية لتسهيل عمليات تحويل العملات البسيطة، وهو ليس مناسبًا تمامًا للتعامل مع منطق الأعمال المعقد. في حين أنه يمكن تنفيذ الوظائف الأساسية مثل التوقيع المتعدد وأقفال الوقت باستخدام لغات البرمجة النصية، فإن الحد الأدنى من معلومات الحالة التي يمكن لـ UTXO الخاص بالبيتكوين تسجيلها يجعلها أقل قدرة على التعامل مع العمليات الأكثر تعقيدًا.

ساهمت القيود المفروضة على UTXO الخاصة بـ Bitcoin بشكل غير مباشر في ظهور "Ethereum". كان فيتاليك، أحد المساهمين الأوائل في مجلة Bitcoin، مدركًا جيدًا لأوجه القصور في Bitcoin. يعالج نموذج الحساب/الرصيد، الذي يسهل على معظم الأشخاص فهمه، التحديات التي تواجهها UTXO في التعامل مع تطبيقات الحالة الغنية. كما ذكر فيتاليك في ورقة عمل إيثريوم:

يمكن إنفاق UTXO أو عدم إنفاقه؛ لا توجد فرصة لعقود أو نصوص متعددة المراحل تحافظ على أي حالة داخلية أخرى تتجاوز ذلك. وهذا يجعل من الصعب إبرام عقود خيارات متعددة المراحل، أو عروض التبادل اللامركزي، أو بروتوكولات التزام التشفير ذات المرحلتين (الضرورية للحصول على مكافآت حسابية آمنة). وهذا يعني أيضًا أنه لا يمكن استخدام UTXO إلا لبناء عقود بسيطة لمرة واحدة وليس عقودًا أكثر تعقيدًا مثل المنظمات اللامركزية، مما يجعل تنفيذ البروتوكولات الفوقية أمرًا صعبًا. الحالة الثنائية المقترنة بعمى القيمة تعني أيضًا أن تطبيقًا مهمًا آخر، وهو حدود السحب، مستحيل.

تطبيق وتحسين وتوسيع نموذج UXTO

قبل الخوض في التطبيقات والتحسينات المختلفة لنموذج UTXO، دعونا نحلل مجالات التحسين مع الحفاظ على مزاياه. ويمكن تلخيصها على النحو التالي:

1. تلخيص معنى الحالة المخزنة في UTXOs.

2. تلخيص ملكية الدولة.

3. حل مشكلات التنافس على الدولة عند مشاركة UTXOs.

في BTC، المعنى الوحيد للحالة هو كمية الرمز المميز، وعادةً ما يتم تعريف الملكية باستخدام المفاتيح العامة، ولا تتم معالجة تنافس الحالة على نطاق واسع لأن BTC لم يتم تصميمه للتطبيقات اللامركزية.

سوي

يوفر Sui للمطورين نوعين من الكائنات: OwnedObject وSharedObject. الأول يشبه UTXO (نسخة محسنة على وجه التحديد)، في حين أن الأخير مشابه لنموذج الحساب/الرصيد. ويمكن استخدام كلاهما في وقت واحد.

يمكن مشاركة الكائن، مما يعني أنه يمكن لأي شخص القراءة أو الكتابة إلى ذلك الكائن. على عكس OwnedObject القابل للتغيير (مع كاتب واحد فقط)، يتطلب SharedObject إجماعًا لترتيب عمليات القراءة والكتابة.

في سلاسل الكتل الأخرى، تتم مشاركة كل كائن. ومع ذلك، يمكن لمطوري Sui عادةً اختيار استخدام OwnedObject أو SharedObject أو مزيج من الاثنين معًا لتنفيذ حالات استخدام محددة. قد يؤثر هذا الاختيار على الأداء والأمان وتعقيد التنفيذ.

في Sui، الكائنات المملوكة تشبه UTXOs، ويمكن لمالكها فقط العمل عليها. تحتوي الكائنات أيضًا على أرقام إصدارات، ولا يمكن لمالكها إنفاق نسخة الكائن إلا مرة واحدة. ولذلك، فإن إصدار الكائن يتوافق بشكل أساسي مع UTXO.

فيما يتعلق بقضايا التنافس على الدولة، يعالجها Sui من خلال معالجة خاصة (الطلب المحلي، على غرار الوقود) في SharedObjects.

كاردانو

يستخدم Cardano نموذج UTXO الموسع المعروف باسم eUTXO. يدعم eUTXO زيادة قابلية البرمجة مع الاحتفاظ بمزايا نموذج Bitcoin UTXO.

في كاردانو، يتم توسيع معنى الدولة بشكل أكبر من خلال النصوص، ويتم تعريف ملكية الدولة بطريقة أكثر عمومية. تُستخدم مجموعات UTXO لتقليل مشكلات التنافس على الحالة. على وجه التحديد، تم تحسين eUTXO في جانبين:

1. يتضمن نموذج eUTXO عناوين أكثر عمومية. لا تعتمد هذه العناوين فقط على تجزئة المفاتيح العامة ولكن يمكن تعريفها بناءً على أي منطق يحدد الشروط التي يمكن بموجبها إنفاق eUTXO، مما يتيح إمكانية برمجة ملكية الدولة.

2. بالإضافة إلى العناوين والقيم، يمكن للمخرجات أن تحمل (تقريبًا) أي بيانات، مما يسمح ببرمجة معنى الحالة من خلال البرامج النصية.

وبشكل أكثر تحديدًا، يسمح eUTXO للمستخدمين بإضافة بيانات عشوائية بتنسيق يشبه JSON إلى UTXOs، يشار إليه باسم Datum. يمكّن Datum المطورين من توفير وظائف تشبه الحالة للنصوص البرمجية المرتبطة بـ UTXOs محددة.

علاوة على ذلك، يمكن للمعاملات على كاردانو أن تحمل معلمات تتعلق بمستخدمين محددين، والمعروفين باسم المخلصين. يسمح المخلص لمبادر المعاملة بتحديد كيفية استخدام UTXOs ويمكن لمطوري التطبيقات اللامركزية استخدامها لأغراض مختلفة.

عندما يتم التحقق من صحة المعاملة، يعمل البرنامج النصي للتحقق باستخدام البيانات والمخلص والسياق الذي يحتوي على بيانات المعاملة. يتضمن هذا البرنامج النصي منطق استخدام UTXOs عند استيفاء الشروط.

تجدر الإشارة إلى أن eUTXO لا يزال يحقق مهام التمديد من خلال البرامج النصية ويختلف بشكل كبير عن المفهوم التقليدي لـ "العقود الذكية" (يقترح تشارلز هوسكينسون، المؤسس، تسميتها "المدقق القابل للبرمجة"، ولكن مصطلح "العقود الذكية" مقبول على نطاق أوسع في السوق).

الأعصاب

في Nervos (CKB)، يتم تلخيص معنى الحالة بواسطة TypeScript، ويتم تجريد ملكية الحالة بواسطة lockscript. نموذج تحسين UTXO البسيط في شكل رمز الخلية هو كما يلي:

بنية النشر CellOutput {

    سعة الحانة: السعة، بيانات حانة 

 : Vec<u8>، قفل حانة 

 : برنامج نصي، نوع حانة 

 : Option<Script>، 

 }

أما بالنسبة لمسألة التنافس على الدولة، فإن CKB يعمل حاليًا على تطوير الأبحاث حول المعاملة المفتوحة، حيث يمكن للمستخدمين اقتراح UTXO جزئي يحدد غرض المعاملة، ثم يقوم صانعو المطابقة بتجميعها في معاملة كاملة.

نموذج خلية Nervos هو نسخة "معممة" من UTXO، وقد قدم جان شرحًا تفصيليًا في منتدى Nervos:

ينصب تركيز Layer1 على الحالة، ومع استخدام Layer1 كهدف للتصميم، يركز CKB بشكل طبيعي على الحالة.

يفصل إيثريوم تاريخ المعاملات وتاريخ الحالة إلى بعدين، حيث تمثل الكتل والمعاملات الأحداث التي تؤدي إلى تحولات الحالة بدلاً من الحالة نفسها. في المقابل، يقوم بروتوكول البيتكوين بدمج المعاملات والحالات في بُعد واحد - المعاملات هي الحالة، والحالة هي المعاملة. إنها بنية تتمحور حول الولاية.

وفي الوقت نفسه، يهدف CKB إلى التحقق والحفاظ ليس فقط على nValue كحالة ولكن أي بيانات تعتبر ذات قيمة ومعتمدة بالإجماع للحفاظ عليها على المدى الطويل. إن هيكل مخرجات معاملات البيتكوين غير مناسب لهذا الغرض، لكنه قدم لنا الكثير من الإلهام. من خلال تعميم nValue وتحويله من مساحة لتخزين الأعداد الصحيحة إلى مساحة قادرة على الاحتفاظ بأي بيانات، نحصل على "CTxOut" أو خلية أكثر عمومية.

في الخلية، تصبح nValue حقلين: السعة والبيانات. تمثل هذه الحقول مجتمعة مساحة تخزين، حيث تكون السعة عددًا صحيحًا يشير إلى حجم المساحة بالبايت، والبيانات هي المكان الذي يتم فيه تخزين الحالة ويمكنها استيعاب أي تسلسل بايت. يصبح scriptPubKey قفلًا، مجرد تغيير في الاسم، يعبر عن مالك مساحة الإجماع هذه - فقط الشخص الذي يمكنه توفير المعلمات (مثل التوقيع) لتنفيذ برنامج القفل النصي بنجاح يمكنه "تحديث" الحالة في هذه الخلية . يجب أن يكون إجمالي عدد البايتات التي تشغلها CellOutput بالكامل أقل من أو يساوي السعة. لدى CKB العديد من الخلايا، وتشكل مجموعتها الحالة الحالية الكاملة لـ CKB، حيث تقوم بتخزين المعرفة المشتركة بدلاً من مجرد عملة رقمية محددة.

لا تزال المعاملات تمثل التغييرات/الهجرات للدولة. يتم التغيير في الحالة أو "تحديث" محتوى الخلية فعليًا من خلال التدمير والإنشاء (وليس عن طريق التعديل المباشر لمحتوى الخلية الأصلية). تقوم كل معاملة بتدمير مجموعة من الخلايا بشكل فعال بينما تقوم في نفس الوقت بإنشاء مجموعة جديدة من الخلايا. تتمتع الخلايا المنشأة حديثًا بمالكين جدد وتقوم بتخزين بيانات جديدة، لكن السعة الإجمالية المدمرة تكون دائمًا أكبر من أو تساوي إجمالي السعة التي تم إنشاؤها، مما يضمن عدم تمكن أي شخص من زيادة السعة بشكل تعسفي. نظرًا لأنه يمكن نقل القدرة ولكن لا يمكن زيادتها بشكل تعسفي، فإن امتلاك القدرة يعادل امتلاك مقدار مماثل من مساحة حالة الإجماع. السعة هي الأصل الأصلي في شبكة CKB. إن تدمير الخلية يؤدي فقط إلى تمييزها على أنها "مدمرة"، على غرار الطريقة التي يتم بها إنفاق Bitcoin UTXOs غير المنفقة ولا تتم إزالتها فعليًا من blockchain. لا يمكن تدمير كل خلية إلا مرة واحدة، تمامًا كما لا يمكن استخدام كل UTXO إلا مرة واحدة.

خصائص هذا النموذج هي:

1. الدولة لها أهمية قصوى.

2. الملكية هي خاصية من سمات الدولة، ولكل دولة مالك واحد.

3. يتم تدمير وإنشاء الدول باستمرار.

لذلك، الخلية هي نسخة عامة من UTXO.

وقود

يعتمد الوقود نموذج قائمة الوصول الصارمة، وهو تحسين UTXO يعتمد على مفهوم العقد UTXO.

كما تم تقديمه سابقًا، فإن UTXO التقليدي في BTC له سمتان فقط: كمية العملة والمالك. في المقابل، يوفر Contract UTXO خصائص أساسية إضافية، بما في ذلك كمية العملة ومعرف العقد وتجزئة رمز العقد وجذر التخزين.

في حالة استخدام نموذج تنفيذ عديم الحالة، يتطلب Contract UTXO فقط تجزئة رمز العقد وجذر التخزين. في نموذج التنفيذ ذو الحالة، يمكن حذف هذه الحقول في عقد UTXO، ولكن هناك حاجة إلى نوع UTXO لعنصر تخزين منفصل. يتم إنشاء معرف UTXO، وهو معرف فريد لكل UTXO يعمل كمفتاح في قاعدة بيانات تخزين قيمة المفتاح، من نقطة إخراج UTXO أو متغيرها (على سبيل المثال، تجزئة نقطة الإخراج وحقولها).

في هذا النموذج، يمكن لأي شخص استدعاء عقد UTXO، المشابه للعقود الذكية.

من الضروري ملاحظة أن Fuel يوفر وظائف أقرب إلى العقود الذكية بدلاً من النصوص البرمجية. إن القيود المفروضة على نموذج UTXO نفسه تجعل تطوير التطبيقات باستخدام VM أمرًا صعبًا، خاصة في التعامل مع مشكلات التنافس على UTXO. هناك بشكل عام ثلاثة حلول: أولاً، المعالجة خارج السلسلة، كما هو الحال في عملية التجميع؛ ثانيًا، العمل الإضافي المسبق الذي تستخدمه شركة فيول؛ ثالثًا، المعاملة المفتوحة المذكورة أعلاه في CKB، حيث يمكن لكل مستخدم اقتراح معاملات جزئية، ويقوم صانع التوفيق (على غرار جهاز التسلسل) بدمجها في معاملات كاملة. الحل المقابل في BTC هو PBST.

خاتمة

من هذه المقالة، اكتسبنا فهمًا للمبادئ الأساسية لـ UTXO، وتعرفنا على نقاط القوة والضعف في نموذجها مقارنة بنموذج الحساب/الرصيد الخاص بـ Ethereum، وحصلنا على رؤية أوضح لمفهوم UTXO وامتداداته ذات الصلة.

باعتباره أحد مبادئ التصميم الأساسية للبيتكوين، يلعب نموذج UTXO دورًا حاسمًا في ضمان أمان المعاملات وإمكانية تتبعها. مع التطور المستمر والتوسع في تكنولوجيا blockchain، تم تطوير نموذج UTXO (مثل EUTXO، والخلية، وقائمة الوصول الصارمة)، مما يوفر المزيد من الإمكانيات لمعاملات وإدارة الأصول الرقمية. من خلال البحث المتعمق وفهم مفهوم UTXO وامتداداته ذات الصلة، يمكننا فهم جوهر تقنية blockchain بشكل أفضل، ووضع أساس أكثر صلابة للابتكارات والتطبيقات المستقبلية.

تنصل:

1. تمت إعادة طباعة هذه المقالة من [极客 Web3]، جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [0xAyA]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Sanv Nurlae ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Sanv Nurlae. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.