تفاصيل حول تحديث Segregated Witness ونتائج اعتماده في Bitcoin

في هذه المقالة ، حاولنا فحص التغييرات في بروتوكول Bitcoin بالتفصيل التي حدثت نتيجة لتحديث Segregated Witness softfork. تطرقنا إلى القضايا المتعلقة بمرونة المعاملات ، والحفاظ على التوافق العكسي ، وزيادة الإنتاجية ، وتنسيقات تسلسل المعاملات الجديدة ، وخيارات البرمجة النصية الجديدة ، وتنسيق عنوان Bech32 ومزاياها ، ومفاهيم الوزن والحجم والحجم الظاهري. علاوة على ذلك ، فيما يلي أهم الإحصائيات حول تكييف التحديث والإجابات على الأسئلة المتداولة حول موضوع هذا التحديث.

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

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

مشكلة قابلية التعامل مع المعاملات وحلها

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

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

1. قم بتغيير تنسيق التوقيع . في بروتوكول Bitcoin ، لا يتم اعتماد تنسيق التوقيع بشكل صارم ويعتمد على تنفيذ مكتبة OpenSSL ، حيث لا يتم أيضًا تحديد التنسيق الصارم للتوقيع. يجوز لطرف ثالث تعديل المعاملة التي تم اعتراضها ، مما سيؤدي إلى تغيير في قيمة التجزئة.
2. التأثير مباشرة على scriptSig . كما ذكرنا سابقًا ، يحتوي scriptSig على مجموعة من العمليات للتحقق من الأدلة على أن مستخدمًا معينًا هو مالك العملات المعدنية. ولكن بالإضافة إلى هذه العمليات ، يمكنك إضافة آخرين إليها. ستؤدي بعض العمليات غير المؤذية التي لا تؤثر على أي شيء إلى تغيير في قيمة تجزئة المعاملة.
   

وبالتالي ، يمكنك تغيير قيمة تجزئة المعاملة بدون الوصول إلى المفاتيح الخاصة. لماذا تغيير قيمة التجزئة غير مرغوب فيه؟

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

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

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

التوافق العكسي عند توزيع كتلة عبر شبكة

وفقًا للقواعد القديمة ، يبلغ الحد الأقصى لحجم الكتلة 1 ميغابايت ويحتوي على معاملات بأدلة مضمنة. في حين تفترض القواعد الجديدة أن الحد الأقصى لحجم الكتلة الأساسية هو 1 ميجابايت ، ولكن بالإضافة إلى ذلك هناك بنية بيانات مع الأدلة. وفقًا لذلك ، يتجاوز الحجم الإجمالي للكتلة الجديدة 1 ميغابايت.

للتوافق مع الإصدارات السابقة ، تسمح قواعد البروتوكول للعقد القديمة بالعمل مع الكتل الجديدة ، ولكنها لن تتلقى الكتلة إلا في التكوين الأساسي بحجم 1 ميغابايت كحد أقصى. هيكل الشاهد غير متاح لهم. العقد الجديدة تحصل على كتلة كاملة مع المعاملات والأدلة. سيساعدك الشكل التالي على التعرف على هذا السؤال.



على اليسار ، رسم تخطيطي لتشغيل بروتوكول Bitcoin قبل تنشيط Segregated Witness. يبلغ الحد الأقصى لحجم الكتلة 1 ميغا بايت ، وقد تم توزيعها بين عقد الشبكة المختلفة في شكل واحد.

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

طرق زيادة الإنتاجية

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

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

تحديث SoftFork. الشاهد المنفصل يسمح لنا بحل هذه المشكلة باستخدام softfork. كيف بالضبط؟ يسمح لنا بتقسيم الكتلة إلى قسمين ، الأول يخزن المعاملات ، والثاني يحتوي على أدلة. في الوقت نفسه ، تتلقى عُقد الشبكة الجديدة كلا الجزأين ، بينما تتلقى العقد القديمة كتلة معاملات 1 ميجا بايت فقط. لا يمكن للعقد القديمة تلقي كتل بأدلة ، وبالتالي لا يمكنها التحقق من صحة المعاملات التي تتلقاها ، ولكن هذا يسمح لها بالمشاركة في بناء الإجماع وليس اللجوء إلى hardfork ، ولكن للتبديل تدريجيًا إلى البرامج الجديدة.

الابتكارات فصل الشاهد

ضع في اعتبارك ما هو مُضمَّن في تحديث Segregated Witness. أول وأهم ابتكار لـ Segregated Witness هو تنسيق تسلسل المعاملات الجديد. بالإضافة إلى الحقول المعروفة بالفعل ، هناك ثلاثة حقول جديدة في المعاملة الجديدة: علامة ، علامة ، والتي يتم استخدامها للإصدار وفي هذه الحالة يتم تعيينها بدقة ، ولكن في البروتوكولات التالية يمكن تغييرها ، بالإضافة إلى حقل الشاهد. الشاهد (بيانات الشاهد) هو في الواقع مجموعة من الأدلة على ملكية العملات المعدنية التي يتم أخذها من الجزء الرئيسي من المعاملة. من الناحية الهيكلية ، يبدو وكأنه مجموعة من المدخلات ، حيث يتوافق كل عنصر بيانات شاهد مع إدخال برقم معين ، مما يسمح لك بمقارنة الأدلة مع عملات معدنية معينة تنفق.

معرّف معاملة الشاهد

للحصول على معرف المعاملة (معرف المعاملة ، txid) ، تحتاج إلى إحضار المعاملة نفسها إلى تسلسل بيانات واحد بتنسيق تسلسل خاص ، ثم الحصول على قيمة التجزئة من تسلسل البيانات هذا. مع ظهور Segregated Witness ، ظهر معرّف جديد ومعرف معاملة الشاهد (wtxid) وتنسيق تسلسل جديد ، على التوالي. بالنسبة للمعاملات القديمة التي تنفق الأموال دون استخدام Segregated Witness ، سيكون wtxid هو نفسه txid لأنه لن تتم إضافة حقول جديدة إلى Segregated Witness.



هناك حاجة إلى Wtxid لبناء شجرة Merkle بديلة للأدلة. يتم بناؤه بنفس الطريقة المستخدمة في المعاملات العادية ، يتم استخدام wtxid فقط بدلاً من تجزئة المعاملة. وفقًا لذلك ، يتم تجزئة wtxid في أزواج وينتج جذر Merkle.

من المهم ملاحظة أن جذر Merkle يتم إدراجه في معاملة قاعدة العملة المعدنية ، وليس في رأس الكتلة. إذا كان الجذر في رأس الكتلة ، فإن بنية الكتلة ستتغير. لا يمكن أن تعمل العقد التي تدعم البروتوكول القديم مع مثل هذه الكتل. وستبقى جميع الجهود للحفاظ على التوافق مع الإصدارات السابقة ضد هذا التضارب. لذلك ، يتم إدراج الجذر في أحد مخرجات معاملة قاعدة العملة. عندما تتحول جميع العقد إلى Segregated Witness ، قد يتغير هذا الموقف وسيتم النظر في أساليب جديدة.

شاهد برامج لتهيئة الظروف لإنفاق العملات

دعونا نلقي نظرة على كيفية بناء نص معاملات الشاهد المنفصل وكيف يسمح لعقد الشبكة القديمة بفهم أن معاملات الشاهد المنفصلة صحيحة ، على الرغم من حقيقة أنها لا تتلقى أدلة على ملكية العملات المعدنية.

يتكون النص البرمجي الذي يصف قواعد إنفاق العملات المعدنية من معاملة شكل جديدة من جزأين. الجزء الأول هو بايت إصدار الشاهد (البايت يحدد إصدار برنامج الشاهد). يمكن أن تأخذ قيمًا من 0 إلى 16 (OP0-OP16) ، والآن تستخدم OP0. في المستقبل ، قد تظهر إصدارات جديدة من البروتوكول مع دعم الإصدارات الأخرى من برنامج الشهود. الجزء الثاني هو برنامج الشهود. يمكن أن يكون لهذا الجزء حجم من 2 إلى 40 بايت.

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

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

خيارات جديدة لتحديد شروط إنفاق العملات

مع تقديم SegWit ، تم اقتراح تنسيقين قياسيين لـ scriptPubKey ، والذي أصبح بديلاً عن التنسيقين الأكثر شيوعًا لوضع قواعد إنفاق العملات قبل ظهور هذا التحديث. دعونا ننظر فيها بالترتيب.

الدفع لمشاهدة تجزئة المفتاح العمومي (P2WPKH) هو نظير للدفع القياسي لتجزئة المفتاح العمومي. ما الفرق؟ كما ذكرنا سابقًا ، فإن scriptSig غير مملوء ويبقى فارغًا. يتم نقل جميع أدلة ملكية العملات المعدنية إلى هيكل بيانات الشهود.

في هذه الحالة ، يتم إدخال البرنامج النصي الذي تم اعتباره سابقًا ، وإصدار وتجزئة المفتاح العام ، وهو برنامج الشاهد ، في scriptPubKey. تميز العقدة على الشبكة مثل هذا البرنامج النصي للإنفاق عن الآخرين بسبب حقيقة أنه يحتوي على نسخة واحدة وحجم بيانات 20 بايت. نسخة أخرى وحجم مختلف يحملان قواعد إنفاق مختلفة.



في هذه الحالة ، يحتوي scriptPubKey على جزأين: رقم إصدار الشاهد هو صفر وقيمة التجزئة للمفتاح العام للمستلم. سيكون ScriptSig فارغًا ، وستحتوي بيانات الشاهد على توقيع إلكتروني ومفتاح عام للتحقق منه.

تجزئة نظام الدفع مقابل الشهادة (P2WSH) هو تناظري للدفع القياسي إلى تجزئة البرنامج النصي. في هذه الحالة ، يمكن استخدام برنامج نصي مخصص لتحديد قواعد إنفاق العملات المعدنية. كيف يميز المضيف مثل هذا البرنامج النصي عن البرنامج السابق؟ في هذه الحالة ، لا تزال النسخة تحتوي على قيمة واحدة ، ويستغرق برنامج الشاهد 32 بايت وهو قيمة تجزئة من البرنامج النصي للشاهد. إذا وصلت معاملة إلى مضيف يحتوي على نص برمجي سيحتوي على الإصدار الأول ، ولكن حجمه سيختلف عن قيم 20 أو 32 بايت ، فسيرفض المضيف هذه المعاملة لأنه لن يعرف كيفية العمل معها.

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

في هذه الحالة ، يحتوي scriptPubKey على جزأين: رقم الشاهد للإصدار هو صفر وقيمة التجزئة لسكربت الشاهد لحالة التوقيع المتعدد 1 من 2. سيكون ScriptSig فارغًا ، وستحتوي بيانات الشاهد على التوقيع الإلكتروني ونص الشاهد الأصلي في نص واضح.

غلاف P2SH

تنسيق النص الجديد يختلف عن القديم. وفقًا لذلك ، لن تعرف الخدمات والمحافظ القديمة كيفية العمل باستخدام تنسيق البرنامج النصي هذا وكيفية تأليفه. من أجل التوافق مع الإصدارات السابقة ، تستخدم معاملات Segregated Witness باستخدام P2SH "غلاف" خاص ، والذي يسمح لك بإنشاء معاملة لها خصائص معاملة Segregated Witness ، ولكنها لا تختلف عن P2SH المعتاد للعالم الخارجي.

يتم استخدام P2SH لتبسيط عمل المرسل وليس عبئه بتفاصيل تنفيذ البرنامج النصي لاسترداد المتلقي. في هذه الحالة ، يمنح المستلم المرسل قيمة تجزئة Redeem Script فقط ، ويمرر البرنامج النصي نفسه إلى scriptSig جنبًا إلى جنب مع الأدلة.



في هذه الحالة ، يحتوي scriptPubKey على عملية تجزئة ، وقيمة تجزئة البرنامج النصي للاسترداد ، وعملية مقارنة (كما هو الحال في الإصدار القديم من P2SH). سيحتوي ScriptSig هنا على قيمة تجزئة المفتاح العمومي ، وستحتوي بيانات الشاهد على التوقيع الإلكتروني والمفتاح العام.

يسمح هذا النهج للمحافظ الرقمية غير المحدثة بإرسال المعاملات إلى عناوين الشهود المنفصلين ، دون معرفة أي شيء عن الطرق الجديدة لتعيين شروط إنفاق العملات المعدنية.

تنسيق عنوان Bech32 جديد

من الجدير بالذكر بشكل منفصل عناوين Bech32 التي تعتبر عناوين SegWit أصلية. بالنسبة لمعظم تاريخها ، استخدمت Bitcoin ترميز Base58 للعناوين مع إضافة المجموع الاختباري ، وهو نتيجة مبتورة للتجزئة المزدوجة باستخدام وظيفة التجزئة SHA-256. لقد كانوا جزءًا من البرنامج الأصلي وتم توسيع نطاقهم في BIP13 لـ P2SH. ولكن لكل من مجموعة الأحرف وخوارزمية المجموع الاختباري قيود:

• يستهلك العنوان الموجود في Base58 المزيد من الذاكرة في رموز QR ، لأنه لا يمكنه استخدام وضع التمثيل الأبجدي الرقمي ؛
• base58 غير مريح للغاية للكتابة الموثوقة على الورق ، أو الكتابة من لوحة المفاتيح المحمولة ، أو القراءة بصوت عالٍ ؛
• تجزئة الاختبارية المزدوجة بطيئة ؛
• فك ترميز base58 معقد وبطيء نسبيًا.

يتضمن تحديث SegWit فئة جديدة من المخارج (برامج الشهود) وحالتين: P2WPKH و P2WSH. وظائفها متاحة بشكل غير مباشر للعقد القديمة من خلال استخدام P2SH ، ولكن سيكون أكثر أمانا وأمانا استخدامها مباشرة ، لذلك من الضروري تقديم تنسيق عنوان جديد.

مواصفات عنوان Bech32

يجب ألا يزيد طول عنوان Bech32 عن 90 حرفًا ويحتوي على:

1. جزء قابل للقراءة البشرية. يتضمن هذا البيانات التي قد يلزم إرسالها أو التي لها علاقة بمالك العنوان ، بطول حرف واحد على الأقل. على سبيل المثال ، بشكل افتراضي لعناوين mainnet ، تكون الأحرف هي "bc" ، وبالنسبة لـ testnet تكون الأحرف "tb".
2. محدد دائمًا 1. إذا كان "1" مسموحًا به داخل الجزء الذي يسهل على الإنسان قراءته ، فإن الفاصل هو آخر الأحرف "1".
   
3. يبلغ طول جزء البيانات 6 أحرف على الأقل ويتكون فقط من أحرف أبجدية رقمية ، باستثناء "1" و "b" و "i" و "o". هنا يتم استخدام نسخة برنامج الشاهد وبيانات برنامج الشاهد نفسه (من 2 إلى 40 بايت) هنا كبيانات رئيسية.
   

لماذا تضمين فاصل في العناوين؟ هذا يسمح لك بفصل الجزء الذي يمكن قراءته عن الإنسان بوضوح عن الجزء الذي يمكن قراءته من البيانات ، وتجنب التصادمات المحتملة مع الأجزاء الأخرى التي يمكن قراءتها بواسطة الإنسان والتي تستخدم البادئة. كما أنه يتجنب قيود مجموعة الأحرف للجزء الذي يمكن قراءته بواسطة الإنسان. الفاصل هو 1 لأن استخدام حرف غير أبجدي رقمي يجعل من الصعب نسخ العناوين (بدون النقر المزدوج في تطبيقات متعددة). لذلك ، تم تحديد حرف أبجدي رقمي خارج مجموعة الأحرف الرئيسية. ويصاحب استخدام نظام الأرقام الأساسي 32 زيادة في طول العنوان بنسبة 15٪ مقارنة بنظام الأرقام 58 الأساسي ، ولكن هذا لا يهم عند نسخ العناوين.

عناوين المجموع الاختباري Bech32

آخر 6 أحرف من العنوان هي المجموع الاختباري. تم بناء المجموع الاختباري على أساس رمز BCH ، والذي يضمن الكشف عن أي خطأ لا يؤثر على أكثر من 4 أحرف ، واحتمال أن يتقارب المجموع الاختباري عند ارتكاب أكثر من 4 أخطاء هو واحد من 109.

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

الأحرف الكبيرة والصغيرة في العنوان

يتم استخدام الأحرف الصغيرة عندما تكون قيمة الحرف مطلوبة من أجل المجموع الاختباري.

يعرض البرنامج دائمًا سلسلة عنوان Bech32 بالكامل في الأحرف الصغيرة.إذا كان إصدار الأحرف الكبيرة مطلوبًا (على سبيل المثال ، للعرض التقديمي أو استخدامه في رمز الاستجابة السريعة) ، فهذا متاح بشكل اختياري. علاوة على ذلك ، لن يقبل البرنامج العناوين التي تكون فيها بعض الأحرف في حالة الأحرف الكبيرة وبعضها في أحرف صغيرة. عادةً ما تكون الأحرف الصغيرة مفضلة للعرض ، ولكن يجب استخدام الأحرف الكبيرة لرموز QR لأنها تسمح بتمثيل أبجدي رقمي مشفر بنسبة 45٪ أكثر من تمثيل البايت.

مفاهيم الوزن وحجم الكتلة

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

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

وزن الكتلة = حجم القاعدة * 3 + الحجم الكلي لحجم

الكتلة - وزن الكتلة (المقاس بوحدات الوزن)
حجم القاعدة - حجم الكتلة الأساسية (المقاسة بالبايت)
الحجم الكلي- حجم الكتلة الإجمالي (يقاس بالبايت)

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

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

جنبا إلى جنب مع الوزن ، تم تقديم مفهوم الحجم الافتراضي ، والذي يتم حسابه بقسمة الوزن على أربعة. يتم استخدام الحجم الافتراضي لحساب العمولات للمعاملات حتى يتمكن المصدقون من فهم مدى فائدة إدراج معاملة معينة في الكتلة باستخدام سعر السجل المعتاد ، والذي يتم قياسه بوحدات spb (satoshi لكل بايت).

الحجم الافتراضي = وحدات الوزن / 4

نظرًا لأن وزن المعاملات للشاهد غير المنفصل سيكون أكبر 4 مرات من الحجم ، فسيكون حجم المعاملة الافتراضية مساوياً للحجم المعتاد. وفقا لذلك ، بالنسبة للمعاملات القديمة ، لن يتغير حساب العمولة. بالنسبة للمعاملات الجديدة ، سيكون أصغر قليلاً ، لأنه يتم تقديم التوقيعات في هيكل منفصل. وبالتالي ، يمكن دفع رسوم أقل لهم ، ولكن عمال المناجم لديهم نفس الأولوية عند تضمينهم في الكتلة. في الوقت نفسه ، يبلغ الحد الأقصى لحجم الكتلة بدون بيانات الشاهد (الحجم الأساسي) 1 ميجابايت ، والحد الأقصى لوزن الكتلة هو 4 ميجابايت.

قد ينشأ سؤال منطقي هنا: "ماذا سيكون حجم الكتلة الفعلي مع بيانات الشاهد؟". من المستحيل بالتأكيد الإجابة عليه. من الواضح أن هذه القيمة ستتراوح من 1 ميجابايت إلى 4 ميجابايت. ولكن يمكن إجراء تقييم نظري أكثر دقة. احصل على حوالي 1.8 ميغابايت. من أين تأتي هذه القيمة؟ تتكون كتلة المعاملات النموذجية حاليًا من حوالي 60٪ من البيانات المفتوحة. إذا قمنا بحساب وزن كتلة 1 ميجابايت ، والتي تتكون من 40٪ من دليل ملكية العملات ، فإننا نحصل على البيانات التالية.

400،000 بايت * 4 = 1،600،000 وحدة تقليدية للوزن
600،000 بايت * 1 = 600،000 وحدة تقليدية للوزن
1،600،000 + 600،000 = 2،200،000 وحدة تقليدية للوزن
4،000،000 / 2،200،000 = 1.81 ميجابايت

أي أنه يمكن افتراض أن حجم الكتلة الفعال سيكون حوالي 1.8 ميغابايت. ولكن من الواضح أنه في الممارسة العملية ستعتمد هذه القيمة بشكل كامل على تكوين المعاملات في هذه الكتلة.

تحديث إحصائيات التكيف

اعتبارًا من يوليو 2018 ، تجاوز عدد معاملات SegWit علامة 35٪ من إجمالي العدد في شبكة Bitcoin. في الوقت نفسه ، نفذت الخدمات الرئيسية للعمل مع Bitcoin والمحافظ الرقمية دعمًا لـ Segregated Witness مؤخرًا (على سبيل المثال ، Electrum و Bitxfy).


الرسم مأخوذ من دراسة بحث BitMex.

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


وفقًا لتحليلات BitMex Research

إذا نظرت إلى اعتماد متوسط ​​رسوم المعاملة على عدد المعاملات بتنسيق جديد ، يمكنك أيضًا رؤية ارتباط قوي جدًا في التغييرات في هذه القيم.

ودعونا لا ننسى أن Segregated Witness جعلت من الممكن تطوير حلول خارج السلسلة فوق بروتوكول Bitcoin. بالطبع ، يعد تكييف شبكة البرق مهمة أكثر صعوبة مقارنةً بـ SegWit ، ومع ذلك ، فإن العمل في هذا الصدد على قدم وساق وهناك إنجازات كبيرة بالفعل.

أسئلة متكررة

- هل من الصحيح أن نقول أن RBF (الاستبدال بالرسوم) لن تعمل في معاملات الشاهد المنفصل؟

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

- كيف يمكنني تغيير تجزئة معاملة غير مؤكدة؟

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

- كيف يتم تخزين بيانات الشهود في المعاملة؟

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

- لماذا لا تستخدم مجموعة أحرف موجودة ، مثل RFC3548 أو z-base-32 لعناوين Bech32؟

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