Maxim Orlovsky ، جمعية معايير LNP/BP
في الورقة ، نقترح طريقة لترقية طبقة البيتكوين 1 (blockchain/timechain) دون وجود softfork المطلوب. ترقية تستفيد من خصائص التحقق من جانب العميل ، يمكن أن تكون تدريجية ، ولديها خيار نشر بدون إذن (أي لا يتطلب دعم الأغلبية أو تعاون عمال المناجم) وسيحصل على قابلية التوسع في الترتيب
اكتسبت كلمة Bitcoin معاني متعددة ، وبالتالي نميزها باستخدام مصطلحات أكثر تحديدًا. نحن نستخدم Bitcoin كمصطلح مظلة عام يدل على النظام ككل ، والذي قد يشمل طبقات متعددة (بما في ذلك بعض المستقبل) والفكرة الإجمالية للنظام النقدي الإلكتروني من نظير إلى نظير ناشئ عن Satoshi Nakamoto. في الوقت نفسه ، نستخدم BTC للإشارة إلى Bitcoin كندرة رقمية وأموال وعملة. نحن نميز أيضًا إجماع Bitcoin POW (قاعدة اختيار المنتج التالي) ، إجماع Nakamoto (والذي يتضمن إجماع POD مع تعزيز وسائل الاقتصاد المشفرة لعقوبة منجم) ، bitcoin blockchain (بدلا من TimeChain ) كتطبيق محدد لطبقة البيتكوين 1 و بروتوكول Bitcoin (BP) كمجموعة من المعايير والتقنيات والأدوات للعمل مع معاملات Bitcoin على السلسلة (في أي طبقة ممكنة 1).
جلب التنفيذ الأصلي لـ Bitcoin by Satoshi Nakamoto الفكرة الغريبة المتمثلة في أن الجميع بحاجة إلى التحقق من المعاملات للعالم بأسره. تلقت هذه الفكرة اسم blockchain ، أو ، في بعض الأحيان ، Timechain - التي أصبحت تعبيرًا عن دفتر الأستاذ مع وصول الجمهور. لقد خلق مقدمة دفتر الأستاذ مشكلتين: عدم قابلية التوسع وضعف الخصوصية ؛ الأول يمنع حدوث تأثير التبني والشبكات ؛ الآخر يتناقض مع روح cypherpunk الأصلية لبيتكوين وتمثل خطر حضاري استراتيجي (انظر حتمية cypherpunk لحضارة مناسبة وبيان cyphernox).
تم معالجة قابلية التوسع ، جزئياً ، في وقت لاحق من خلال إدخال أنظمة الطبقة 2 ، مثل شبكة البرق والحلول المقترحة الأخرى. من بين هؤلاء ، كانت فكرة Sidechain الأقل ثمرًا ، والتي ورثت معظم (إن لم يكن كلها) من قيود تقنية blockchain الأصلية مع حل مشكلة انخفاض البرمجة ، خلقت صندوقًا رملًا للتجارب ، وبعض جوانب الخصوصية جزئيًا. شبكة Lightning Network - حل طبقة 2 أكثر نجاحًا يتم نشره بالفعل وتشغيله - له مشكلات قابلية التوسع الخاصة بها بسبب الحاجة إلى الإفراط في التحمل السيولة ، وقيود إنتاجية ثرثرة (كلاهما يؤدي إلى مركزية الشبكة) وانخفاض الأمن/الثقة تحت ظروف طبقة قاعدة عالية [..]. تتطلب البدائل الأخرى المقترحة ، مثل ARK ، عدة تغييرات في الطبقة الأساسية (واحدة أو اثنين من الحالات الناعمة) ، والتي تمثل تحديات للنشر. أخيرًا ، لا تحل أي من حلول الطبقة الثانية الحالية أو المقترحة مشكلات خصوصية طبقة Bitcoin الأصلية ، وحلول Layer-1 الأخرى التي تركز على الخصوصية (مثل Coinjoin) لا تحمي من السلطات القانونية وتقدم مشاكل فطرية إضافية BTC.
وبالتالي ، يمكن أن نستنتج أن نهج blockchain المستند إلى دفتر الأستاذ لبناء الطبقة 1 والذي يجب أن يتم التفكير فيه بالكامل من أجل حل المشكلات المذكورة أعلاه. جاءت الأفكار الأولى في هذا المجال مع عودة بيتر تود في عامي 2016 و 2017 عندما أشار إلى أن مالكي بعض الحالة (على سبيل المثال BTC أو أي عقد دولة آخر) يحتاجون إلى التحقق من جزء من تاريخ المعاملات - الجزء الذي هو مرتبطة مباشرة بملكيتهم - وحذف الباقي. أطلق على نهجه التحقق من صحة من جانب العميل . صمم Giacomo Zucco بروتوكول قادر على إنشاء أصول مع هذا النهج ، المسمى RGB . في عملي السابق في جمعية معايير LNP/BP ، تمكنت من تطوير RGB بشكل أكبر وتحويله إلى نظام العقد الذكي الذكي العام الأول مع حالة غنية وحساب محدود ، مما يوفر وظائف كافية لتشغيل أي شيء أي شيء أي شيء أي شيء أي شيء أي شيء أي شيء أي شيء. يمكن القيام به من خلال العقود الذكية المستندة إلى blockchain-ولكن بدون قيام دفتر الأستاذ/blockchain العام بتخزين أي بيانات مستخدم ، باستخدام خصائص إجماع POW لبروتوكول Bitcoin POW مباشرة. تم تطوير هذا النظام علنًا خلال أربع سنوات وتم إصداره في أبريل 2023.
في الاقتراح الحالي ، نوضح أن Bitcoin ، إذا تم تزويدها بطبقة من جانب العميل المليئة بالمرض (مثل RGB) ، يمكن ترقيتها إلى نظام دون خصائص محددة لدفتر الأستاذ العام (blockchain) ، ومع الحفاظ على بروتوكول إجماع POW ، يمكن إعادة بناءها على طبقة جديدة غير قابلة للتطوير غير قابلة للتطوير 1 ( Prime CodeNamed). ستكون هذه الطبقة قادرة على استضافة عدد من المعاملات غير المحددة نظريًا (على الأقل مليارات في الدقيقة) نظرًا لأن تخزين الحالة والحوسبة والتحقق من الصحة سيتم نقلها إلى الطبقة المعتمدة من جانب العميل أعلاه. لا يتطلب مثل هذا التصميم شبكة البرق أو غيرها من طبقات التوسع والدفع في الأعلى وتوسيع نطاقه في سيناريو أسوأ الحالات
يحتوي البروتوكول على ثلاثة خيارات للنشر (بدون إذن ، وتنشيط عمال المناجم و Softfork) ، مع أول اثنين لا يتطلب أي شوكة ناعمة (أو صلبة). الخيارات مستقلة ، ولكن يمكن نشرها أيضًا بطريقة ناتجة عن ذلك.
يوفر الاقتراح العديد من الفوائد لبيتكوين كنقد رقمي:
بعض العيوب النسبية للنظام المقترح هي:
يتكون النظام المقترح ( PRIME ) من أربعة مكونات رئيسية:
هذه المكونات مكافئة بشكل مشترك في وظائفها إلى دفتر الأستاذ من نوع blockchain ؛ ومع ذلك ، في تصميمنا ، أصبحوا مستخلصين ، مما يوفر قابلية التوسع والخصوصية أكثر بكثير من أي نظام blockchain آخر.
في مؤسستها ، تدير Prime خدمة الطابع الزمني ، مما يؤدي إلى إنشاء سلسلة من الرؤوس ، كل واحد يلتزم بجذر شجرة Merkle لبيانات من جانب العميل الخارجي:
classdiagram
الاتجاه LR
`header n` <|-` header n+1`
فئة `header n` {
Prev_Commitment
merkle_root
merkle_tree_height
الطابع الزمني
// أسير الحقول
TLV_EXTENTES
}
فئة `header n+1` {
Prev_Commitment
merkle_root
merkle_tree_height
الطابع الزمني
// أسير الحقول
TLV_EXTENTES
}
تم تجهيز كل رأس بتمديد TLV اختياري ، والذي يمكن استخدامه لترقيات بروتوكول المستقبل ؛ حجمها مستقل عن عدد المعاملات الواردة في شجرة Merkle للبيانات التي يتم صياغتها من جانب العميل وهي من 100 بايت (اعتمادًا على بيانات TLV).
Prime لا يوفر أي حماية من الإنفاق المزدوج ؛ سيتم توفيره من قبل جزء من النظام من جانب العميل من النظام. الأجزاء الوحيدة من نظام الطابع الزمني الذي يتم التحقق منه (قواعد الإجماع) هي:
الرؤوس الأولية هي المعلومات الوحيدة المطلوبة لتكون متاحة علنًا وعالميًا ؛ يمكن تحقيق ذلك باستخدام شبكة P2P الموزعة.
أشجار Merkle Proof ( PMT ) هي بنية وسيطة وفتحة تربط بين البيانات التي يتم صياغتها من جانب العميل إلى الرؤوس. يتم إنتاج PMTs من قبل عمال المناجم ويتيحون للجمهور عبر نفس أو بعض الوسائل الأخرى مثل الرؤوس ؛ ومع ذلك ، على عكس الرؤوس ، فهي غير مطلوبة للاستمرار. يتتبع كل مستخدم شبكة جميع PMTs الجديدة ، ويستخرج جزءًا من المعلومات المتعلقة بالحالة التي تملكها ، ويقوم بحفظها في مخبأها من البيانات المهددة من جانب العميل وتجاهل بقية PMT.
نظرًا للطبيعة سريعة الزوال ، وغياب التحقق من الصحة ولا حاجة في معرفة محتوى PMT لاستخراج الرأس التالي ، فإن حجم PMT لا يؤثر على قابلية توسيع النظام. وبالتالي ، قد يكون PMT بحجم جيجابايت (متعدد) ، ملتزمًا بمليارات ومليارات المعاملات.
تحتوي أوراق الأشجار على شهود يغلقون خداعًا للاستخدام الواحد: وهي آلية موصوفة بالتفصيل في القسم التالي. يتم إنشاء PMTs وفقًا لمخطط الالتزام الحتمي متعدد البروتوكول LNPBP-4 ويستخدم في RGB اليوم لاستضافة الالتزامات في معاملات البيتكوين (كلا من بروتوكولات السلسلة وداخلها مثل البرق). هذا يعني أن كل خبز واحد للاستخدام لديه موضع فريد محدد مسبقًا في PMT ، بحيث يكون مسار Merkle واحد وشاهد ورقة كافية لإثبات الإغلاق-أو غياب الإغلاق-لعلاج محدد للاستخدام الواحد في إعطاء رأس. تتبع المستخدمين مجموعة من seals ذات الاستخدام الواحد والتي لم يتم إغلاقها بعد (التماثلي من مجموعة UTXO) واستخراج البراهين النسبية من كل PMT المنتج حديثًا. إذا لم يتم إغلاق أختامهم ، فهذه أدلة على عدم التهوية (لأن الشاهد يوضح وجود خفق مختلف للاستخدام الواحد يتم إغلاقه في هذا المسار).
تشكل البراهين جزءًا متزايدًا يعتمد على الوقت من التاريخ الذي تم تسهيله من جانب العميل. سوف تنمو متطلبات الذاكرة للعقدة بطريقة تعتمد على الوقت كما
أين
هذا أفضل من الناحية اللغارية من قابلية التوسع لأي عقدة blockchain ، حيث تنمو متطلبات الذاكرة مثل
أين
أين
ال
أين
يمنع بروتوكول الخبز المفرد للاستخدام الهجمات المزدوجة على النظام.
تعتبر SEALS ذات الاستخدام الواحد (أو الأختام ) شكلًا خاصًا من الالتزام التشفير الذي اقترحه بيتر تود. يمكن مقارنة البدائية بأشكال أخرى من الالتزامات التشفير التي تشمل وظائف التجزئة والطابع الزمني:
ويرد مزيد من المعلومات حول بناء seals للاستخدام الواحد في معيار LNPBP-8. يستخدم Prime شكلًا مصممًا بشكل خاص من SEALS ذات الاستخدام الواحد الذي يختلف عن تلك المستخدمة في البروتوكولات الموجودة (مثل RGB).
يتكون تعريف الخبز الوحيد للاستخدام من مكونين:
unique_id : معرف أنشأ المستخدم العالمي ، والذي يمكن إنشاؤه بشكل حتمي من العقد ، وتجزئة العقد ، ورقم تشغيل العقد ؛spending_conditions_cmt : الالتزام (التجزئة) للشروط التي يمكن بموجبها إغلاق الختم في المستقبل (على غرار scriptPubkey في إخراج معاملة Bitcoin). يتم تعريف الأختام في نظام العقد الذكي من جانب العميل (RGB أو RGB-like). قد يكون لكل ختم حالة مخصصة (كما في RGB) ، على سبيل المثال ، BTC Balance أو أي بيانات غنية أخرى. عندما يحب المستخدم تحديث تلك الحالة-أو نقل ملكيته إلى مستخدم آخر ، يجب إعداد انتقال الحالة ، وتحديد (SEAL) الجديد للاستخدام الواحد والدولة الجديدة. بعد ذلك ، يتم إنشاء شاهد من أن يتم بناء خبز الاستخدام الواحد ، والالتزام ببيانات انتقال الدولة وتوفير البرنامج النصي المصدر ، ومطابقة الالتزام بظروف الإنفاق ، والبيانات التي تفي بهذا البرنامج النصي/الشروط. ملخصات الاقتراح من نظام برمجة محددة يستخدم (يمكن أن يكون البساطة ، ALUVM كما في RGB اليوم ، على أمل عدم EVM :) ؛ يمكن تحديد محرك البرمجة النصية باستخدام حقل version ، بحيث يمكن تقديم محركات أو رموز أوفات جديدة بمرور الوقت (انظر قسم الترقية):
classdiagram
الاتجاه LR
التعريف <|- شاهد: فريد من نوعه.
تعريف الفئة {
فريد
الإنفاق _conditions_cmt
}
شاهد فئة {
إصدار
فريد
state_transition_cmt
الإنفاق _conditions_src
الرضا
}
يتم وضع الشاهد في شكل صريح داخل ورقة من ptree ويقدم لعملين مناجم ، وبناء ptree والرؤوس. يجب وضع الورقة داخل شجرة Merkle بشكل حتمي فيما يتعلق بـ Seal unique_id ، على سبيل المثال في الفتحة
يسمح مسار merkle إلى الورقة المطابقة unique_id ، إلى جانب محتويات الأوراق (توفير بيانات الشاهد) بالتحقق من أن كل خدعة استخدام واحدة تم إغلاقها مرة واحدة فقط في تاريخ العقد الذكي-وأنه تم إغلاقه لإرضاء النصوص شروط. يرجى ملاحظة أنه يجب تجميع البراهين لكل unique_id للاستخدام الفردي من وقت تعريفها حتى الإغلاق-شرط لإثبات أنه لم يتم إغلاق الختم بينهما. هذه الأدلة ، طالما أنها تظهر فريدة مختلفة unique_id ، قد تحذف شروط الإنفاق الحساسة للخصوصية وبيانات المصدر وبيانات الرضا ، مما يوفر فقط تجزئةهم ؛ وبالتالي قد يكون الشهود التاريخيون من الحجم الثابت. كما ذكرنا من قبل ، لأغراض قابلية التوسع ، يمكن أيضًا ضغط تاريخ البراهين باستخدام أدلة المعرفة الصفرية.
سيتطلب النظام ، عند نشره بخيار بدون إذن ، بروتوكول الإجماع الخاص به. إن أمان البروتوكول ليس حاسماً ، لأنه مرتبط بأمان أسير العمل في Bitcoin مع آلية مخصصة موضحة أدناه. الشرط الوحيد للإجماع هو أن يكون مقاومًا للرقابة ، مما يعني مجموعة مفتوحة من عمال المناجم/المدققون أقل من الهوية. بروتوكولات الإجماع الوحيدة المعروفة بأنها ترضي هذه الخصائص هما POW و Ouroboros crypsinous البديل من BFT الإجماع المضمّن من قبل مكافآت Miner.
خدمة الطابع الزمني لا تتكيف أي عملة مشفرة ، ويتم مكافأة عمال المناجم بالرسوم من اليوم الأول. ، stablecoin أو مدفوعات رمزية). يجب أن يشارك عمال المناجم في شبكة P2P المجهولة بدون إذن ، حيث ينشر مستخدمو البروتوكولات شهودهم المجهزين بالمعاملات التي تدفع رسومًا إلى "من يلعب الرأس التالي". يتضمن عمال المناجم هذه المعاملات في تاريخهم الذي يصحّب من جانب العميل ، ومن خلال القيام بذلك ، يتمتعون بالقدرة على استخدام الأموال المكتسبة في المستقبل.
في لحظة إطلاق النظام ، يتم إنشاء ناتج مخصص "أي شخص" مع كمية أعلى من SATs على bitcoin blockchain. تصبح المعلومات حول هذا UTXO جزءًا من Genesis وتعمل كتعريف لختم الاستخدام الواحد للتعدين . يجب أن يقضي عامل منجم حل تحدي الأسرى هذا الإخراج وداخل معاملة Bitcoin الإنفاق ، يوفر التزام Tapret برأس ملغّن ودقة جديدة للاستخدام الفردي "أي شخص من أي شخص" للعاملين التاليين. هذا يثبت الرأس الذي تم إنشاؤه إلى blockchain Bitcoin بطريقة فريدة ، بحيث أن تسلسل رأس الطابع الزمني الوحيد الصحيح هو التسلسل الذي يتبع هذا التسلسل من seals ذات الاستخدام الواحد.
إذا كان أحد الطرفين ينفق عملاً حاليًا للاستخدام الواحد دون خلق التزام-أو الالتزام برأس دون أن يسير الأسلحة المساجد ، فإن هذا الإغلاق يعتبر غير صالح ؛ في هذه الحالة ، يُسمح لأي طرف بإنشاء معاملة خاصة من Bitcoin توفر معلومات OP_RETURN التي لا يمكن تحديدها بشكل عام ("إعلان") حول مُعد منجم جديد للاستخدام ( إعادة تعيين البروتوكول ) ؛ يعتبر إعلان OP_RETURN الأول فقط الذي يتم إغلاقه مع إجراء مناسب صالحًا بموجب قواعد الإجماع.
يمثل ترسيخ SONE-SEAL للاستخدام الواحد بروتوكول إجماع كامل يمكن تشغيله بواسطة النظام دون أي إجماع إضافي آخر (POW أو BFT). بدلاً من ذلك ، يمكن دمجها مع إجماع ثانوي مع قاعدة أنه ما لم يكن أمان بروتوكول الإجماع الثاني أقل من أمان Bitcoin POW ، فإن Bitcoin POW لديه الأولوية - مع التبديل التلقائي إلى الإجماع الثانوي كإجماع أساسي عند هذا لم يتم الوفاء بالشرط.
نحن لا نعالج عمداً مسألة بنية شبكة P2P في هذا الاقتراح ، لأن أنظمة بديلة متعددة قد تتعايش وتتنافس بطريقة تعتمد على السوق. بدلاً من ذلك ، نظرًا لأن خصائص الشبكة مهمة لأهداف المشروع ، فإننا نحدد المتطلبات العامة لاختيار شبكة P2P:
في اللحظة الحالية من الوقت ، لا نرى شبكة تلبية العقارات المذكورة أعلاه ؛ ومع ذلك ، نرى العديد من الشبكات مع إمكانية التطوير تجاههم:
نحن نخطط للعمل في مشروع Renosttr ، مع الاستفادة من عملنا السابق من بروتوكول العاصفة واستخدام التشفير من طرف إلى طرف BIP-324. قد تقوم المشاريع الأخرى ببناء حلول بديلة ، ويجب تحديد الخيار الأفضل من قبل السوق.
نرى ثلاث خطوات - أو خيارات - في كيفية نشر الحل المقترح في Bitcoin. كل خطوة اختيارية ؛ يمكن للنظام العمل دون أي واحد أو اثنين منهم. أيضا ، كل خيار له مفاضلات خاصة به ، ومع ذلك ، إذا تم نشرها مع الخطوات الناتجة ، يتم حل هذه المقايضات تدريجيا.
يمكن إطلاق النظام بشكل مستقل عن Bitcoin Timechain ، مع إجماع الإجماع على أمان Bitcoin POD عبر آلية مخصصة تستند إلى خداع للاستخدام الواحد (الذي نصفه في الورقة). هذا لا يتطلب أي تغييرات على جانب عمال المناجم أو أي بيتكوين ناعمة/قاسية ، ولكن مع هذا الإعداد يمكن نقل BTC إلى النظام الجديد بلا موثوق فقط بطريقة واحدة - والطريقة الأخرى سوف تتطلب اتحاد.
يبدأ عمال المناجم في Bitcoin في معالجة المعاملات الأولية ووضع الالتزام برؤوس خدمة الطابع الزمني إلى Bitcoin blockchain coinbase - كما يفعلون في حالة التعدين المدمج. هذا يزيل الحاجة إلى إجماع رئيسي مخصص ، ولكنه عرضة لهجمات هاشد هجمات ، مما يتطلب من الغالبية العظمى من عمال المناجم الانضمام إلى البروتوكول قبل نشره.
ومع ذلك ، لا يتطلب الاقتراح أي SoftFork محددة ، مع قواعد إجماع Bitcoin الحالية ، لا يمكن أن يوفر وسيلة غير موثوقة لنقل BTC من نظام Prime الجديد إلى bitcoin blockchain. على الرغم من أننا لا نرى ذلك كشرط (لدى Prime العديد من الفوائد على blockchain بحيث نعتبر blockchain ميتة بالفعل على المدى الطويل) ، على المدى القصير قد يمثل هذا تحديًا لاعتماد المنصة.
هناك الكثير من المقترحات المختلفة التي قد تتيح هذه الوظيفة. تندرج في فئتين رئيسيتين:
إن تبني أي من هذه المقترحات سيسمح بإخراج غير موثوق به لـ BTC على المنصة الأولية. تفضيلاتنا الخاصة بعد الرموز المرجعية التي تتمثل في معرفة المعرفة ، لأنها لديها العديد من الفوائد الأخرى ولا توفر مفاضلات لا مفر منها في القيادة.
يختلف ترقية نظام صياغة من جانب العميل بشكل كبير عن قابلية الترقية (مثل البرق) أو شبكة P2P (مثل Lightning). يحدث هذا بسبب حقيقة أن blockchains هي بروتوكولات الإجماع التي يتم تكرارها بالكامل آلات الحالة ، في حين أن التحقق من صحة من جانب العميل يستخدم النسخ المتماثل الجزئي. هذا ، من ناحية ، يجعل من الأسهل ترقية النظام في أجزاء مرتبطة بحالة غير معروفة-ولكن من ناحية أخرى ، بسبب عدم وجود ضمانات غير محفوظة على الاقتصاد على حالة يمكن الوصول إليها عالميًا توفرها الشبكة ، من الصعب تنسيق أي ترقية.
بمعنى آخر ، تختلف ترقيات التحقق من صحة من جانب العميل اختلافًا جذريًا عن الحالات الصلبة في blockchain و Softforks ، وتتطلب إدخال مفاهيم وشروط جديدة.
إذا كان هناك شيء غير صالح وأصبح صالحًا بعد الترقية (نسمي هذا التغيير السريع إلى الأمام ) ، فلن يتأثر جميع المستخدمين الحاليين: إنهم يمتلكون بالفعل ويديرون الحالة الصالحة. ومع ذلك ، قد لا يكونون قادرين على التفاعل مع المستخدمين الذين يقومون بتشغيل الإصدارات الأقدم من البرنامج - وهو أمر قابل للحل إذا وافق أقرانهم على الترقية. لا تعرض الترقية أي خطر على هؤلاء الأقران لأنهم لن يستخدموا أيًا من الحالة التي يمتلكونها - ولن تلمس الترقية البيانات التاريخية.
من ناحية أخرى ، فإن الموقف عندما كان هناك شيء صالح - وأصبح غير صالح بموجب القواعد الجديدة - مختلف تمامًا: قد يفقد المستخدمون حالتهم الحالية إلى الأبد ويجب أن يعارضوا الترقية قدر الإمكان. نحن نسمي مثل هذه الترقيات الخلفية للضغط ، ونرى أنها مقبولة فقط إذا تم اكتشاف خطأ حرج: سيتم "التنسيق" للترقية من خلال رغبة المستخدمين المخلصين/غير المخلوقين لتجنب المشكلات التي أدخلها الخطأ.
إذا تم استخدام نظام RGB أو RGB المستوحى من نظام العقد الذكي ، فستكون للترقيات إلى هذا الجزء ميزة مميزة أخرى. RGB يعزل كل برنامج ("العقد الذكي") في صندوق رمل ؛ وعقد ، بمجرد إصداره ، لا يمكن الترقية إلى الإصدار الجديد من البروتوكول. الطريقة الوحيدة للترقية هي إنتاج عقد جديد عندما يقوم المصدر (أو الأطراف التي تم تفويضها من قبل المصدرين ، بما في ذلك المجتمع) بنقل الدولة من العقد القديم إلى العقد الجديد - وكل واحد من العقد سوف يتفق المالكون على ذلك.
وكفائدة جانبية ، يسمح هذا النهج بإدخال ميزات تدريجية للميزات الجديدة ، والتعليمات ، وما إلى ذلك ، غير قابلة للتحقيق في عالم blockchain: لا يعتمد مصدري العقود الجديدة على إصدارات البروتوكول السابقة ويمكنهم اقتراح حلول أكثر تقدماً دون أي خطر ترقية أو تنسيق المجتمع.
المؤلف ممتن لـ Giacomo Zucco ، الذي كان الشخص الذي يفترض فكرة إزالة الاعتماد على البيتكوين على blockchain المقيد ورؤية التحقق من صحة العميل كوسيلة إلى الأمام. ساعدت مناقشات متعددة معه وبيتر تود على مر السنين في تصميم العديد من أجزاء النظام. من بين آخرين ، يود المؤلف أن يذكر أليكس كرافيتس ، فيديريكو تينغا ، أولغا أوكولوفا الذين كانوا من المحاورين الذين أمضوا ساعات طويلة في مناقشة الأمور المتعلقة بالتحقق من صحة من جانب العميل ، وعيوب بلوكشين ، وتصميمات أقل من blockchain.
