Cosmos: Jaringan Buku Besar Terdistribusi

بقلم Jae Kwon and Ethan Buchman · 2016

مقدمة

النجاح المشترك للنظام البيئي مفتوح المصدر، المشاركة اللامركزية، والعملات المشفرة العامة ألهمت فهم بروتوكولات الإنترنت اللامركزية يمكن استخدامها لتحسين البنية التحتية الاجتماعية والاقتصادية بشكل جذري. لقد رأينا تطبيقات blockchain متخصصة مثل Bitcoin [1] (أ العملة المشفرة)، Zerocash [2] (عملة مشفرة للخصوصية)، و منصات smart contract المعممة مثل Ethereum [3]، مع عدد لا يحصى من التطبيقات الموزعة لـ Etherium Virtual الآلة (EVM) مثل Augur (سوق التنبؤ) وTheDAO [4] (نادي استثماري). ومع ذلك، حتى الآن، عانى هؤلاء blockchain من عدد من المشاكل من العيوب، بما في ذلك عدم كفاءة الطاقة الإجمالية، أو الفقراء أو الأداء المحدود، وآليات الحوكمة غير الناضجة. مقترحات لتوسيع نطاق معاملات Bitcoin، مثل الشاهد المنفصل [5] و BitcoinNG [6]، عبارة عن مقياس رأسي الحلول التي تظل محدودة بقدرة جسدية واحدة الآلة، وذلك لضمان خاصية المراجعة الكاملة. يمكن أن تساعد الشبكة المسرّعة [7] في توسيع نطاق المعاملات Bitcoin

الحجم عن طريق ترك بعض المعاملات خارج دفتر الأستاذ تمامًا، وهو مناسب تمامًا للمدفوعات الصغيرة والحفاظ على الخصوصية قضبان الدفع، ولكنها قد لا تكون مناسبة لمزيد من التعميم احتياجات التحجيم. الحل المثالي هو الذي يسمح بتعدد blockchains المتوازية التفاعل مع الاحتفاظ بخصائصها الأمنية. هذا قد ثبت أنه صعب، إن لم يكن مستحيلاً، مع proof-of-work. تم الدمج التعدين، على سبيل المثال، يسمح بالعمل المنجز لتأمين أحد الوالدين السلسلة ليتم إعادة استخدامها في سلسلة فرعية، ولكن يجب أن تظل المعاملات كذلك تم التحقق من صحتها، بالترتيب، بواسطة كل عقدة، وتم الدمج blockchain يكون عرضة للهجوم إذا كانت أغلبية hashing السلطة على لا يقوم الوالد بدمج تعدين الطفل بشكل نشط. مراجعة أكاديمية يتم توفير بنيات الشبكة البديلة blockchain سياق إضافي، ونقدم ملخصات للمقترحات الأخرى وعيوبها في الأعمال ذات الصلة. نقدم هنا Cosmos، بنية شبكة جديدة blockchain الذي يعالج كل هذه المشاكل. Cosmos عبارة عن شبكة تضم الكثيرين blockchains مستقلة، تسمى المناطق. يتم تشغيل المناطق بواسطة Tendermint Core [8]، والذي يوفر أداءً عاليًا، محرك إجماع متسق وآمن يشبه PBFT، حيث تضمن المساءلة الصارمة للفرعية التحكم في سلوك البرامج الضارة الجهات الفاعلة. تعتبر خوارزمية الإجماع BFT الخاصة بـ Tendermint Core مناسبة تمامًا لتوسيع النطاق العام proof-of-stake blockchains. المنطقة الأولى في Cosmos تسمى Cosmos Hub. Cosmos Hub عبارة عن عملة مشفرة متعددة الأصول proof-of-stake ذات قيمة بسيطة آلية الحوكمة التي تمكن الشبكة من التكيف و ترقية. بالإضافة إلى ذلك، يمكن تمديد المحور Cosmos بواسطة ربط مناطق أخرى. يتواصل مركز ومناطق شبكة Cosmos معها بعضهما البعض عبر بروتوكول اتصال inter-blockchain (IBC)، نوع UDP أو TCP افتراضي لـ blockchains. يمكن أن تكون الرموز يتم نقلها من منطقة إلى أخرى بشكل آمن وسريعدون الحاجة إلى سيولة التبادل بين المناطق. بدلا من ذلك، جميع عمليات النقل بين المناطق token تمر عبر مركز Cosmos، والذي يتتبع المبلغ الإجمالي لـ tokens الذي تحتفظ به كل منطقة. ال يعزل المحور كل منطقة عن فشل المناطق الأخرى. لان يمكن لأي شخص توصيل منطقة جديدة بمركز Cosmos، كما تسمح المناطق بذلك من أجل التوافق المستقبلي مع ابتكارات blockchain الجديدة. في هذا القسم نصف بروتوكول توافق Tendermint والواجهة المستخدمة لبناء التطبيقات بها. للمزيد التفاصيل، انظر الملحق. في الخوارزميات البيزنطية الكلاسيكية المتسامحة مع الأخطاء (BFT)، كل عقدة له نفس الوزن. في Tendermint، العقد لها قيمة غير سلبية مقدار قوة التصويت، والعقد التي لها تصويت إيجابي تسمى الطاقة validators. يشارك المصادقون في بروتوكول الإجماع عن طريق بث التوقيعات المشفرة، أو الأصوات، للاتفاق على الكتلة التالية. يتم تحديد صلاحيات التصويت للمصادقين عند النشأة، أو يتم تحديدها تم تغييره بشكل حتمي بواسطة blockchain، اعتمادًا على application. على سبيل المثال، في تطبيق proof-of-stake مثل مركز Cosmos، قد يتم تحديد قوة التصويت بواسطة مبلغ staking tokens مرهون كضمان. ملاحظة: تشير الكسور مثل ⅔ و⅓ إلى أجزاء من إجمالي التصويت الطاقة، لا العدد الإجمالي لـ validators أبدًا، ما لم يكن كل validators لها وزن متساوي. >⅔ تعني "أكثر من ⅔"، ≥⅓ تعني "على الأقل". ⅓". Tendermint هو بروتوكول إجماع BFT متزامن جزئيًا مشتقة من خوارزمية إجماع DLS [20]. النعناع هو

يتميز ببساطته وأدائه ومسؤوليته. يتطلب البروتوكول مجموعة yxed المعروفة من validators، حيث يكون كل منها يتم التعرف على validator بواسطة مفتاحهم العام. يحاول المدققون القيام بذلك التوصل إلى توافق في الآراء بشأن كتلة واحدة في كل مرة، حيث تكون الكتلة عبارة عن قائمة من المعاملات. يستمر التصويت للتوافق على الكتلة جولات. كل جولة لها قائد مستدير أو مقترح يقترح كتلة. ثم يصوت validators، على مراحل، على ما إذا كان ذلك أم لا لقبول الكتلة المقترحة أو الانتقال إلى الجولة التالية. ال يتم اختيار مقدم العرض للجولة بشكل حتمي من الأمر قائمة validators، بما يتناسب مع قوة التصويت الخاصة بهم. يتم وصف التفاصيل الكاملة للبروتوكول هنا. أمان Tendermint مستمد من استخدامه للبيزنطية المثالية التسامح مع الخطأ من خلال التصويت بالأغلبية العظمى (>⅔) والقفل آلية. ويضمنون معًا ما يلي: ≥⅓ قوة التصويت يجب أن تكون بيزنطية للتسبب في انتهاك السلامة، حيث يتم الالتزام بأكثر من قيمتين. إذا نجحت أي مجموعة من validators في انتهاك السلامة، أو حتى محاولات القيام بذلك، يمكن التعرف عليهم من خلال البروتوكول. هذا يشمل كلا من التصويت للكتل conzicting والبث أصوات غير مبررة على الرغم من ضماناته القوية، يقدم Tendermint منتجات استثنائية الأداء. في معايير 64 عقدة موزعة على 7 مراكز البيانات في 5 قارات، في المثيلات السحابية للسلع الأساسية، يمكن لتوافق Tendermint معالجة آلاف المعاملات لكل ثانيًا، مع فترات استجابة للالتزام تتراوح من ثانية إلى ثانيتين. والجدير بالذكر أن أداء ما يزيد عن ألف معاملة لكل يتم الحفاظ على الثانية حتى في ظروف الخصومة القاسية validators يعطل أو يبث أصواتًا ضارة. انظر ygur أدناه للحصول على التفاصيل.

Tendermint throughput vs block size benchmarked across 64 nodes in 7 datacenters on 5 continents

تم تبسيط إحدى المزايا الرئيسية لخوارزمية الإجماع الخاصة بـ Tendermint أمان العميل الخفيف، مما يجعله مرشحًا مثاليًا للهواتف المحمولة و حالات استخدام إنترنت الأشياء. بينما يجب على العميل الخفيف Bitcoin المزامنة سلاسل رؤوس الكتل والسلسلة التي تحتوي على أكبر دليل على ذلك في العمل، يحتاج عملاء Tendermint Light فقط إلى مواكبة التغييرات إلى مجموعة validator، ثم تحقق من >⅔ PreCommits في أحدث كتلة لتحديد أحدث حالة. تعمل أيضًا أدلة العميل الخفيفة المقتضبة على تمكين inter-blockchain الاتصالات. لدى Tendermint إجراءات وقائية لمنع حدوث بعض الأمراض الهجمات الملحوظة، مثل عمليات الإنفاق المزدوجة بعيدة المدى التي لا تنطوي على أي شيء على المحك والرقابة. وتناقش هذه بشكل كامل في الملحق.يتم تنفيذ خوارزمية إجماع Tendermint في ملف برنامج يسمى Tendermint الأساسية. Tendermint Core هو "محرك الإجماع" الحيادي للتطبيق والذي يمكنه تشغيل أي تطبيق تطبيق الصندوق الأسود الحتمي في نسخة متماثلة موزعة blockchain. يتصل Tendermint Core بتطبيقات blockchain عبر واجهة Blockchain للتطبيق (ABCI) [17]. وبالتالي، ABCI يسمح ببرمجة تطبيقات blockchain في أي اللغة، وليس فقط لغة البرمجة التي تم الإجماع عليها تمت كتابة المحرك. بالإضافة إلى ذلك، ABCI يجعل من الممكن بسهولة قم بتبديل طبقة الإجماع لأي مكدس blockchain موجود. نرسم تشبيهًا بالعملة المشفرة المعروفة Bitcoin. Bitcoin هي عملة مشفرة blockchain حيث تحتفظ كل عقدة قاعدة بيانات لمخرجات المعاملات غير المنفقة (UTXO) المدققة بالكامل. إذا أراد أحدهم إنشاء نظام يشبه Bitcoin أعلى ABCI، سيكون Tendermint Core مسؤولاً عن مشاركة الكتل والمعاملات بين العقد إنشاء ترتيب قانوني/غير قابل للتغيير للمعاملات ( blockchain) وفي الوقت نفسه، سيكون تطبيق ABCI مسؤولاً عن ذلك صيانة قاعدة البيانات UTXO التحقق من صحة التوقيعات المشفرة للمعاملات منع المعاملات من صرف أموال غير موجودة السماح للعملاء بالاستعلام عن قاعدة البيانات UTXO Tendermint قادر على تحليل تصميم blockchain بواسطة تقديم واجهة برمجة تطبيقات بسيطة جدًا بين عملية تقديم الطلب و عملية الإجماع.

Perkenalan

Keberhasilan gabungan dari ekosistem sumber terbuka, pembagian yle yang terdesentralisasi, dan cryptocurrency publik memilikinya mengilhami pemahaman bahwa protokol internet terdesentralisasi dapat digunakan untuk secara radikal memperbaiki infrastruktur sosio-ekonomi. Kami telah melihat aplikasi blockchain khusus seperti Bitcoin [1] (a cryptocurrency), Zerocash [2] (mata uang kripto untuk privasi), dan platform smart contract yang digeneralisasi seperti Ethereum [3], dengan aplikasi terdistribusi yang tak terhitung jumlahnya untuk Etherium Virtual Mesin (EVM) seperti Augur (pasar prediksi) dan TheDAO [4] (klub investasi). Namun hingga saat ini, blockchain ini telah menderita sejumlah penyakit kelemahannya, termasuk inefisiensi energi yang besar, buruk atau kinerja yang terbatas, dan mekanisme tata kelola yang belum matang. Proposal untuk menskalakan throughput transaksi Bitcoin, seperti Saksi Terpisah [5] dan BitcoinNG [6], merupakan penskalaan vertikal solusi yang tetap dibatasi oleh kapasitas fisik tunggal mesin, untuk memastikan properti kemampuan audit yang lengkap. Lightning Network [7] dapat membantu menskalakan transaksi Bitcoin

volume dengan meninggalkan beberapa transaksi dari buku besar sepenuhnya, dan sangat cocok untuk pembayaran mikro dan menjaga privasi jalur pembayaran, tetapi mungkin tidak cocok untuk yang lebih umum kebutuhan penskalaan. Solusi ideal adalah solusi yang memungkinkan beberapa blockchain paralel untuk saling beroperasi dengan tetap mempertahankan properti keamanannya. Ini sudah terbukti sulit, bahkan tidak mungkin, dengan proof-of-work. Digabung pertambangan, misalnya, memungkinkan pekerjaan dilakukan untuk mengamankan orang tua rantai untuk digunakan kembali pada rantai anak, tetapi transaksi tetap harus dilakukan divalidasi, secara berurutan, oleh setiap node, dan blockchain yang ditambang gabungan rentan terhadap serangan jika mayoritas hash berkuasa di orang tua tidak aktif menggabungkan penambangan anak. Tinjauan akademis arsitektur jaringan blockchain alternatif disediakan konteks tambahan, dan kami memberikan ringkasan proposal lainnya dan kekurangannya dalam Pekerjaan Terkait. Di sini kami menyajikan Cosmos, arsitektur jaringan blockchain baru yang mengatasi semua masalah ini. Cosmos adalah jaringan yang terdiri dari banyak jaringan blockchains independen, disebut zona. Zona ini didukung oleh Tendermint Core [8], yang memberikan kinerja tinggi, mesin konsensus seperti PBFT yang konsisten dan aman, dengan jaminan akuntabilitas forka yang ketat terhadap perilaku pelaku jahat aktor. Algoritme konsensus BFT Tendermint Core sangat cocok untuk menskalakan proof-of-stake blockchains publik. Zona pertama di Cosmos disebut Hub Cosmos. Cosmos Hub adalah cryptocurrency multi-aset proof-of-stake dengan sederhana mekanisme tata kelola yang memungkinkan jaringan untuk beradaptasi dan meningkatkan. Selain itu, Hub Cosmos dapat diperluas sebesar menghubungkan zona lain. Hub dan zona jaringan Cosmos berkomunikasi satu sama lain melalui protokol komunikasi antar-blockchain (IBC), semacam UDP atau TCP virtual untuk blockchains. Token bisa saja ditransfer dari satu zona ke zona lain dengan aman dan cepattanpa memerlukan likuiditas pertukaran antar zona. Sebaliknya, semua transfer token antar zona melalui Hub Cosmos, yang melacak jumlah total token yang dimiliki oleh setiap zona. Itu hub mengisolasi setiap zona dari kegagalan zona lainnya. Karena siapa pun dapat menghubungkan zona baru ke Hub Cosmos, zona mengizinkan untuk kompatibilitas di masa depan dengan inovasi blockchain baru. Pada bagian ini kami menjelaskan protokol konsensus Tendermint dan antarmuka yang digunakan untuk membangun aplikasi dengannya. Untuk lebih lanjut selengkapnya lihat lampiran. Dalam algoritma toleransi kesalahan Bizantium klasik (BFT), setiap node mempunyai berat yang sama. Di Tendermint, node memiliki non-negatif jumlah hak suara, dan node yang memiliki suara positif kekuatan disebut validators. Validator berpartisipasi dalam protokol konsensus dengan menyiarkan tanda tangan kriptografi, atau suara, untuk menyetujui blok berikutnya. Hak suara validator ditentukan sejak awal, atau memang demikian diubah secara deterministik oleh blockchain, bergantung pada aplikasi. Misalnya pada aplikasi proof-of-stake seperti Hub Cosmos, hak suara dapat ditentukan oleh sejumlah staking tokens diikatkan sebagai jaminan. CATATAN: Pecahan seperti ⅔ dan ⅓ mengacu pada pecahan dari total suara daya, tidak pernah jumlah total validator, kecuali semua validator mempunyai bobot yang sama. >⅔ artinya “lebih dari ⅔”, ≥⅓ artinya “setidaknya ⅓”. Tendermint adalah protokol konsensus BFT yang sinkron sebagian berasal dari algoritma konsensus DLS [20]. Tendermint adalah

terkenal karena kesederhanaan, kinerja, dan akuntabilitas forknya. Protokol ini memerlukan kumpulan validator yang diketahui, dimana masing-masing validator diidentifikasi oleh kunci publiknya. Validator mencoba untuk mencapai konsensus mengenai satu blok pada satu waktu, di mana satu blok adalah sebuah daftar transaksi. Pemungutan suara untuk konsensus mengenai suatu blok sedang berlangsung putaran. Setiap putaran memiliki pemimpin putaran, atau pengusul, yang mengusulkan sebuah blok. validators kemudian melakukan pemungutan suara, secara bertahap, untuk menentukan apakah akan melakukan hal tersebut atau tidak untuk menerima blok yang diusulkan atau melanjutkan ke babak berikutnya. Itu pengusul putaran dipilih secara deterministik dari yang dipesan daftar validators, sebanding dengan hak suara mereka. Rincian lengkap protokol dijelaskan di sini. Keamanan Tendermint berasal dari penggunaan Bizantium yang optimal toleransi kesalahan melalui pemungutan suara super-mayoritas (>⅔) dan penguncian mekanisme. Bersama-sama, mereka memastikan bahwa: ≥⅓ hak suara harus dimiliki Bizantium agar dapat menyebabkan pelanggaran keselamatan, di mana lebih dari dua nilai berkomitmen. jika ada kumpulan validator yang berhasil melanggar keselamatan, atau bahkan upaya untuk melakukannya, mereka dapat diidentifikasi oleh protokol. Ini mencakup pemungutan suara untuk blok konziktif dan penyiaran suara yang tidak adil. Meski jaminannya kuat, Tendermint memberikan yang luar biasa kinerja. Dalam benchmark dari 64 node yang didistribusikan di 7 pusat data di 5 benua, pada instance cloud komoditas, Konsensus Tendermint dapat memproses ribuan transaksi per kedua, dengan latensi penerapan dalam urutan satu hingga dua detik. Khususnya, kinerja lebih dari seribu transaksi per yang kedua dipertahankan bahkan dalam kondisi permusuhan yang keras, dengan validators mogok atau menyiarkan suara perusak yang jahat. Lihat gambar di bawah untuk detailnya.

Tendermint throughput vs block size benchmarked across 64 nodes in 7 datacenters on 5 continents

Manfaat utama dari algoritma konsensus Tendermint disederhanakan keamanan klien yang ringan, menjadikannya kandidat ideal untuk seluler dan kasus penggunaan internet-of-thing. Sedangkan klien ringan Bitcoin harus melakukan sinkronisasi rantai header blok dan temukan yang memiliki bukti paling banyak berhasil, klien ringan Tendermint hanya perlu mengikuti perubahan ke set validator, lalu verifikasi >⅔ PreCommits di blok terbaru untuk menentukan keadaan terkini. Bukti klien ringan yang ringkas juga memungkinkan antar-blockchain komunikasi. Tendermint memiliki tindakan perlindungan untuk mencegah hal tertentu serangan penting, seperti pembelanjaan ganda jangka panjang tanpa mempertaruhkan apa pun dan sensor. Hal ini dibahas lebih lengkap dalam lampiran.Algoritma konsensus Tendermint diimplementasikan dalam a program yang disebut Tendermint Core. Tendermint Inti adalah “mesin konsensus” agnostik aplikasi yang dapat mengubah apa pun aplikasi blackbox deterministik menjadi direplikasi secara terdistribusi blockchain. Tendermint Core terhubung ke blockchain aplikasi melalui Antarmuka Aplikasi Blockchain (ABCI) [17]. Jadi, ABCI memungkinkan blockchain aplikasi diprogram di mana saja bahasa, bukan hanya bahasa pemrograman yang disepakati mesin ditulis. Selain itu, ABCI memungkinkannya dengan mudah tukar lapisan konsensus dari tumpukan blockchain yang ada. Kami menggambar analogi dengan cryptocurrency terkenal Bitcoin. Bitcoin adalah mata uang kripto blockchain yang dikelola oleh setiap node database Hasil Transaksi Tak Terpakai (UTXO) yang telah diaudit sepenuhnya. Jika seseorang ingin membuat sistem seperti Bitcoin di atas ABCI, Tendermint Core akan bertanggung jawab Berbagi blok dan transaksi antar node Menetapkan tatanan transaksi yang kanonik/tidak dapat diubah (the blockchain) Sementara itu, aplikasi ABCI akan bertanggung jawab Memelihara basis data UTXO Memvalidasi tanda tangan kriptografi transaksi Mencegah transaksi mengeluarkan dana yang tidak ada Mengizinkan klien menanyakan database UTXO Tendermint mampu menguraikan desain blockchain dengan menawarkan API yang sangat sederhana antara proses aplikasi dan proses konsensus.

Cosmos الهندسة المعمارية

Cosmos عبارة عن شبكة متوازية مستقلة blockchains كل منها مدعوم بخوارزميات الإجماع الكلاسيكية BFT مثل النعناع 1. سيكون blockchain الأول في هذه الشبكة هو Cosmos Hub. ال Cosmos يتصل المحور بالعديد من blockchains (أو المناطق) عبر بروتوكول اتصال جديد بين blockchain. المركز Cosmos يتتبع العديد من أنواع token ويحتفظ بسجل للمجموع عدد tokens في كل منطقة متصلة. يمكن أن تكون الرموز يتم نقلها من منطقة إلى أخرى بشكل آمن وسريع دون الحاجة إلى تبادل السوائل بين المناطق، لأن جميعها تتم عمليات تحويل العملات بين المناطق عبر مركز Cosmos. تعمل هذه البنية على حل العديد من المشكلات المتعلقة بمساحة blockchain يواجه اليوم، مثل قابلية التشغيل البيني للتطبيقات، وقابلية التوسع، و إمكانية الترقية السلسة. على سبيل المثال، المناطق المشتقة من Bitcoind، يمكنك الانتقال إلى Ethereum أو CryptoNote أو ZCash أو أي نظام blockchain يتم توصيله بمركز Cosmos. تسمح هذه المناطق لـ Cosmos بذلك التوسع بشكل لا نهائي لتلبية الطلب على المعاملات العالمية. المناطق هي أيضا يعد خيارًا رائعًا للتبادل الموزع، والذي سيتم دعمه كـ حسنا. Cosmos ليس مجرد دفتر أستاذ موزع، وCosmos Hub ليس حديقة مسورة أو مركز الكون. نحن كذلك تصميم بروتوكول لشبكة مفتوحة من دفاتر الأستاذ الموزعة والتي يمكن أن تكون بمثابة أساس جديد للأنظمة المالية المستقبلية، على أساس مبادئ التشفير والاقتصاد السليم والإجماع النظرية والشفافية والمساءلة. يعد مركز Cosmos هو المركز العام الأول blockchain في Cosmos الشبكة، مدعومة بخوارزمية الإجماع BFT الخاصة بـ Tendermint. ال تم إنشاء مشروع Tendermint مفتوح المصدر في عام 2014 لمعالجة المشكلة السرعة وقابلية التوسع والمشكلات البيئية المتعلقة بخوارزمية إجماع إثبات العمل الخاصة بـ Bitcoin. باستخدام وتحسين ما ثبت

BFT خوارزميات تم تطويرها في معهد ماساتشوستس للتكنولوجيا في عام 1988 [20]، Tendermint كان الفريق أول من قدم عرضًا مفاهيميًا لـ proof-of-stake عملة مشفرة تعالج مشكلة عدم وجود شيء على المحك عانى الجيل الأول من العملات المشفرة proof-of-stake مثل مثل NXT وBitShares1.0. اليوم، تستخدم جميع محافظ الهاتف المحمول Bitcoin تقريبًا خوادم موثوقة تزويدهم بالتحقق من المعاملة. وذلك لأن إثبات العمل يتطلب انتظار العديد من التأكيدات قبل يمكن اعتبار المعاملة ملتزمة بشكل لا رجعة فيه. لقد تم بالفعل عرض هجمات Doublespend على خدمات مثل CoinBase. على عكس أنظمة الإجماع blockchain الأخرى، تقدم Tendermint التحقق من الدفع عبر الهاتف المحمول بشكل فوري وآمن. نظرًا لأن Tendermint مصمم بحيث لا يتشعب أبدًا على الإطلاق، فهو متنقل يمكن أن تتلقى المحافظ تأكيدًا فوريًا للمعاملات، مما يجعل المدفوعات غير الموثوقة والعملية حقيقة واقعة على الهواتف الذكية. هذا له تأثيرات كبيرة على تطبيقات إنترنت الأشياء مثل حسنا. يتمتع المدققون في Cosmos بدور مماثل لعمال المناجم Bitcoin، ولكن بدلاً من ذلك استخدم التوقيعات المشفرة للتصويت. المصادقون هم آلات آمنة ومخصصة مسؤولة عن الالتزام كتل. يمكن لغير validators تفويض staking tokens (يُسمى "الذرات") إلى أي validator لكسب جزء من رسوم الكتلة والذرة المكافآت، لكنهم يتعرضون لخطر العقاب (القطع) إذا تم اختراق المندوب validator أو انتهاك البروتوكول. ثبت ضمانات سلامة Tendermint BFT الإجماع والضمانات إيداع أصحاب المصلحة – validator والمفوضين – تقديم أمان يمكن إثباته وقابل للقياس للعقد والعملاء الخفيفين. يجب أن تحتوي الدفاتر العامة الموزعة على دستور و نظام الحكم. Bitcoin يعتمد على Bitcoin الأساس والتعدين لتنسيق الترقيات، ولكن هذه عملية بطيئة. تم تقسيم Ethereum إلى ETH وETC بعد التفرع الصعب للمعالجة يعود سبب الاختراق DAO إلى حد كبير إلى عدم وجود عقد اجتماعي مسبق ولا آلية لاتخاذ مثل هذه القرارات. يمكن للمصادقين والمفوضين في Cosmos التصويت عليهم المقترحات التي يمكن أن تغير المعلمات المحددة مسبقًا للنظام تلقائيا (مثل حد الغاز كتلة)، وتنسيق الترقيات، كما وكذلك التصويت على تعديلات الدستور الذي يمكن قراءته بواسطة الإنسان التي تحكم سياسات Cosmos Hub. الدستور يسمح بالتماسك بين أصحاب المصلحة بشأن قضايا مثل السرقة والأخطاء (مثل حادثة DAO)، مما يسمح بإجراء أسرع وأسرع دقة أنظف. يمكن أن يكون لكل منطقة أيضًا دستورها ونظام حكمها الخاص آلية كذلك. على سبيل المثال، يمكن أن يحتوي المركز Cosmos على الدستور الذي يفرض الثبات في المركز (لا يوجد تراجع، حفظ الأخطاء في تنفيذ العقدة المركزية Cosmos)، بينما يمكن لكل منطقة وضع سياساتها الخاصة فيما يتعلق بالتراجع. ومن خلال تمكين إمكانية التشغيل البيني بين مناطق السياسة المختلفة، فإن تمنح شبكة Cosmos مستخدميها الحرية المطلقة والإمكانات تجريب غير مسموح به. نحن هنا نصف نموذجًا جديدًا للامركزية وقابلية التوسع. Cosmos عبارة عن شبكة تضم العديد من blockchains التي يتم تشغيلها بواسطة النعناع. بينما تهدف المقترحات الحالية إلى إنشاء "فردية". blockchain" مع إجمالي طلب المعاملات العالمية، Cosmos يسمح للعديد من blockchains بالعمل بشكل متزامن مع بعضها البعض مع الاحتفاظ بإمكانية التشغيل البيني. في الأساس، يدير Cosmos Hub العديد من المستقلين blockchains تسمى "المناطق" (يشار إليها أحيانًا باسم "الأجزاء"، في إشارة إلى تقنية قياس قاعدة البيانات المعروفة باسم "التقسيم").

دفق مستمر من عمليات الحظر الأخيرة من المناطق المنشورة عليها يسمح Hub للمركز بمواكبة حالة كل منطقة. وبالمثل، فإن كل منطقة تواكب حالة المحور (لكن المناطق لا يواكبون بعضهم البعض إلا بشكل غير مباشر من خلال المحور). ثم يتم إرسال حزم المعلومات من واحدة منطقة إلى أخرى عن طريق نشر أدلة Merkle كدليل على أن تم إرسال المعلومات واستلامها. وتسمى هذه الآلية التواصل بين blockchain، أو IBC للاختصار. يمكن لأي من المناطق أن تكون في حد ذاتها محاورًا لتكوين رسم بياني غير دوري، ولكن من أجل الوضوح سنصف فقط ما هو بسيط conyguration حيث لا يوجد سوى محور واحد، والعديد من غير المحور المناطق. مركز Cosmos هو blockchain الذي يستضيف أصولًا متعددة دفتر الأستاذ الموزع، حيث يمكن الاحتفاظ بـ tokens بواسطة مستخدمين فرديين أو حسب المناطق نفسها. يمكن نقل هذه tokens من منطقة واحدة إلى أخرى في حزمة خاصة IBC تسمى "حزمة العملات المعدنية". المحور هو مسؤولة عن الحفاظ على الثبات العالمي للمجموع مقدار كل token عبر المناطق. IBC حزمة العملات المعدنية يجب أن يتم تنفيذ المعاملات من قبل المرسل والمركز والمتلقي blockchains.نظرًا لأن Cosmos Hub يعمل بمثابة دفتر الأستاذ المركزي للكل النظام، فإن أمن المركز له أهمية قصوى. بينما قد تكون كل منطقة عبارة عن Tendermint blockchain مؤمنة بواسطة as عدد قليل يصل إلى 4 (أو حتى أقل إذا لم يكن هناك حاجة إلى إجماع BFT)، المحور يجب تأمينها من خلال مجموعة لامركزية عالميًا من validators يمكن أن تصمد أمام سيناريوهات الهجوم الأكثر خطورة، مثل تقسيم الشبكة القارية أو هجوم ترعاه الدولة القومية. منطقة Cosmos هي منطقة blockchain مستقلة تتبادل IBC الرسائل مع المحور. من وجهة نظر المحور، المنطقة هي أ حساب متعدد التوقيع للعضوية الديناميكية المتعددة الأصول يمكن إرسال واستقبال tokens باستخدام IBC الحزم. مثل أ حساب العملة المشفرة، لا يمكن للمنطقة نقل أكثر من tokens من إنه موجود بالفعل، ولكن يمكنه تلقي tokens من الآخرين الذين لديهم تلك الرسائل. منطقة قد يتم تعيينه كـ "مصدر" لواحد أو أكثر من أنواع token، ومنحها القدرة على تعزيز هذا العرض token. قد يتم تثبيت ذرات المركز Cosmos بواسطة validators في المنطقة متصل بالمحور. بينما تشن الهجمات المزدوجة الإنفاق على هذه المناطق من شأنه أن يؤدي إلى خفض الذرات مع المسؤولية الجزئية لـ Tendermint، وهي منطقة حيث يكون >⅔ من قوة التصويت يمكن للبيزنطيين ارتكاب حالة باطلة. مركز Cosmos لا يفعل ذلك التحقق من أو تنفيذ المعاملات المرتكبة في مناطق أخرى، لذلك هو عليه مسؤولية المستخدمين عن إرسال tokens إلى المناطق التي يثقون بها. في المستقبل، قد يجتاز نظام إدارة Cosmos Hub Hub مقترحات التحسين التي تفسر فشل المنطقة. ل على سبيل المثال، قد تكون عمليات النقل الصادرة token من بعض (أو جميع) المناطق يتم خنقها للسماح بقطع دائرة الطوارئ للمناطق (وقف مؤقت لعمليات نقل token) عند اكتشاف هجوم. الآن ننظر إلى كيفية تواصل المركز والمناطق مع كل منهما أخرى. على سبيل المثال، إذا كان هناك ثلاثة blockchains، "Zone1"، "Zone2"،

Cosmos hub and zones architecture showing the Cosmos Hub connecting multiple independent zones via IBC

و"Hub"، ونتمنى أن تقوم "Zone1" بإنتاج حزمة متجهة بالنسبة لـ "Zone2" التي تمر عبر "Hub". لنقل حزمة من واحد blockchain إلى آخر، يتم نشر إثبات على سلسلة الاستلام. يشير الدليل إلى أن سلسلة الإرسال نشرت حزمة لـ الوجهة المزعومة لكي تتحقق السلسلة المتلقية من هذا الإثبات، يجب عليها يجب أن يكون قادرًا على مواكبة رؤوس كتلة المرسل. هذا الآلية مشابهة لتلك المستخدمة في السلاسل الجانبية، الأمر الذي يتطلب سلسلتين متفاعلتين لتكون على علم ببعضهما البعض عبر أ تيار ثنائي الاتجاه من مخططات بيانات إثبات الوجود (المعاملات). من الطبيعي أن يتم فك بروتوكول IBC باستخدام نوعين من المعاملات: معاملة  IBCBlockCommitTx ، والتي تسمح بـ blockchain لإثبات لأي مراقب أحدث كتلة لها-hash، ومعاملة IBCPacketTx، والتي تسمح لـ blockchain بـ أثبت لأي مراقب أن الحزمة المحددة قد تم نشرها بالفعل عن طريق تطبيق المرسل، عبر خاصية Merkle-proof للأحدث كتلة-hash. من خلال تقسيم آليات IBC إلى معاملتين منفصلتين، فإننا السماح لآلية سوق الرسوم المحلية لسلسلة الاستقبال بذلك تحديد الحزم التي سيتم الالتزام بها (أي تم الاعتراف بها)، بينما السماح بالحرية الكاملة لسلسلة الإرسال فيما يتعلق بكيفية ذلك يُسمح بالعديد من الحزم الصادرة. في المثال أعلاه، من أجل تحديث الكتلة-hash الخاصة بـ "Zone1" على "Hub" (أو "Hub" في "Zone2")، IBCBlockCommitTxيجب نشر المعاملة على "المركز" مع الكتلة-hash من "Zone1" (أو على "Zone2" مع الكتلة-hash من "Hub"). راجع IBCBlockCommitTx وIBCPacketTx لمزيد من المعلومات على نوعي المعاملات IBC. بنفس الطريقة التي يكون بها Bitcoin أكثر أمانًا من خلال كونه موزعًا، يمكننا أن نجعل التبادلات أقل عرضة للخطر اختراقات خارجية وداخلية عن طريق تشغيله على blockchain. نحن نسمي هذا التبادل الموزع. ما يسميه مجتمع العملات المشفرة اللامركزية تعتمد البورصة اليوم على ما يسمى معاملات "السلسلة الذرية" (AXC). مع معاملة AXC، هناك مستخدمان قيد التشغيل يمكن لسلسلتين مختلفتين إجراء معاملتي تحويل ملتزمة معًا في كلا الدفترين، أو لا شيء على الإطلاق (أي: ذرياً). على سبيل المثال، يمكن لاثنين من المستخدمين تداول عملات البيتكوين مقابل الأثير (أو أي اثنين من tokens في دفتري أستاذ مختلفين) باستخدام معاملات AXC، على الرغم من أن Bitcoin وEthereum غير متصلين ببعضهما أخرى. إن فائدة تشغيل البورصة على معاملات AXC هي أنه لا يحتاج المستخدمون إلى الثقة ببعضهم البعض أو في مطابقة التجارة الخدمة. الجانب السلبي هو أن كلا الطرفين يجب أن يكونا متصلين بالإنترنت التجارة أن تحدث. نوع آخر من التبادل اللامركزي هو التبادل الجماعي التبادل الموزع الذي يعمل من تلقاء نفسه blockchain. المستخدمين على يمكن لهذا النوع من التبادل إرسال أمر محدد وتحويله إيقاف تشغيل الكمبيوتر، ويمكن تنفيذ التجارة دون أن يكون المستخدم موجودًا على الانترنت. يطابق blockchain ويكمل التداول نيابةً عنه من التاجر.

Cosmos Arsitektur

Cosmos adalah jaringan blockchain paralel independen yang masing-masing didukung oleh algoritma konsensus BFT klasik seperti permen mint 1. blockchain pertama di jaringan ini akan menjadi Cosmos Hub. Itu Cosmos Hub terhubung ke banyak blockchain (atau zona) lainnya melalui a protokol komunikasi antar-blockchain yang baru. Pusat Cosmos melacak berbagai jenis token dan mencatat totalnya jumlah tokens di setiap zona yang terhubung. Token bisa saja ditransfer dari satu zona ke zona lain dengan aman dan cepat tanpa perlu adanya pertukaran cair antar zona, karena semuanya transfer koin antar zona melalui Hub Cosmos. Arsitektur ini memecahkan banyak masalah pada ruang blockchain yang dihadapi saat ini, seperti interoperabilitas aplikasi, skalabilitas, dan kemampuan upgrade yang mulus. Misalnya, zona yang berasal dari Bitcoind, Go-Ethereum, CryptoNote, ZCash, atau sistem blockchain apa pun bisa dicolokkan ke Hub Cosmos. Zona ini mengizinkan Cosmos untuk berkembang pesat untuk memenuhi permintaan transaksi global. Zona juga hal yang bagus untuk pertukaran terdistribusi, yang akan didukung sebagai baik. Cosmos bukan hanya satu buku besar yang didistribusikan, dan Cosmos Hub bukanlah taman bertembok atau pusat alam semesta. Kami adalah merancang protokol untuk jaringan terbuka buku besar terdistribusi yang dapat berfungsi sebagai landasan baru bagi sistem keuangan masa depan, berdasarkan prinsip kriptografi, ekonomi yang sehat, konsensus teori, transparansi, dan akuntabilitas. Cosmos Hub adalah blockchain publik pertama di Cosmos Jaringan, didukung oleh algoritma konsensus BFT Tendermint. Itu Proyek sumber terbuka Tendermint lahir pada tahun 2014 untuk mengatasi masalah tersebut masalah kecepatan, skalabilitas, dan lingkungan dari algoritma konsensus bukti kerja Bitcoin. Dengan menggunakan dan meningkatkan yang sudah terbukti

BFT algoritma dikembangkan di MIT pada tahun 1988 [20], Tendermint tim adalah yang pertama secara konseptual mendemonstrasikan proof-of-stake cryptocurrency yang mengatasi masalah tidak ada yang dipertaruhkan diderita oleh proof-of-stake cryptocurrency generasi pertama tersebut seperti NXT dan BitShares1.0. Saat ini, hampir semua dompet seluler Bitcoin menggunakan server tepercaya memberi mereka verifikasi transaksi. Hal ini karena pembuktian kerja memerlukan menunggu banyak konfirmasi sebelum a transaksi dapat dianggap dilakukan secara permanen. Serangan doublespend telah ditunjukkan pada layanan seperti Basis Koin. Tidak seperti sistem konsensus blockchain lainnya, Tendermint menawarkan verifikasi pembayaran klien seluler yang instan dan terbukti aman. Karena Tendermint dirancang untuk tidak pernah bercabang sama sekali, bersifat mobile dompet dapat menerima konfirmasi transaksi instan, yang menghasilkan pembayaran yang tidak dapat dipercaya dan praktis menjadi kenyataan di ponsel pintar. Ini memiliki dampak yang signifikan terhadap aplikasi Internet of Things baik. Validator di Cosmos memiliki peran serupa dengan Bitcoin penambang, namun sebagai gantinya gunakan tanda tangan kriptografi untuk memilih. Validator adalah mesin yang aman dan berdedikasi yang bertanggung jawab untuk melakukan blok. Non-validators dapat mendelegasikan staking tokens mereka (disebut “atom”) ke validator mana pun untuk mendapatkan sebagian biaya blok dan atom imbalan, namun menimbulkan risiko dihukum (dipotong) jika delegasi validator diretas atau melanggar protokol. Yang terbukti jaminan keamanan konsensus Tendermint BFT, dan agunannya setoran pemangku kepentingan–validators dan delegator–disediakan keamanan yang dapat dibuktikan dan diukur untuk node dan klien ringan. Buku besar publik yang didistribusikan harus memiliki konstitusi dan a sistem pemerintahan. Bitcoin bergantung pada Bitcoin Yayasan danpenambangan untuk mengoordinasikan peningkatan, tetapi ini adalah proses yang lambat. Ethereum dipecah menjadi ETH dan ETC setelah sulit diatasi PeretasanDAO, terutama karena tidak ada kontrak sosial sebelumnya maupun mekanisme untuk mengambil keputusan tersebut. Validator dan delegasi di Hub Cosmos dapat memberikan suara proposal yang dapat mengubah parameter sistem yang telah ditetapkan secara otomatis (seperti batas blok gas), mengkoordinasikan peningkatan, seperti serta memberikan suara pada amandemen konstitusi yang dapat dibaca manusia yang mengatur kebijakan Hub Cosmos. Konstitusi memungkinkan kohesi di antara para pemangku kepentingan dalam isu-isu seperti pencurian dan bug (seperti insiden TheDAO), memungkinkan untuk lebih cepat dan resolusi yang lebih bersih. Setiap zona juga dapat memiliki konstitusi dan pemerintahannya sendiri mekanismenya juga. Misalnya, Hub Cosmos dapat memiliki a konstitusi yang menegakkan kekekalan di Hub (tidak ada kemunduran, kecuali bug implementasi simpul Hub Cosmos), sementara setiap zona dapat menetapkan kebijakannya sendiri mengenai roll-back. Dengan memungkinkan interoperabilitas antar zona kebijakan yang berbeda, Jaringan Cosmos memberi penggunanya kebebasan dan potensi tertinggi eksperimen tanpa izin. Di sini kami menggambarkan model baru desentralisasi dan skalabilitas. Cosmos adalah jaringan yang terdiri dari banyak blockchain yang didukung oleh permen lembut. Sementara proposal yang ada bertujuan untuk menciptakan “single blockchain” dengan total pemesanan transaksi global, Cosmos mengizinkan banyak blockchain untuk dijalankan secara bersamaan satu sama lain dengan tetap mempertahankan interoperabilitas. Pada dasarnya, Hub Cosmos mengelola banyak hal secara independen blockchains disebut “zona” (terkadang disebut sebagai “pecahan”, dalam bahasa Inggris referensi ke teknik penskalaan basis data yang dikenal sebagai "sharding").

Aliran konstan dari blok terbaru yang dilakukan dari zona yang diposting Hub memungkinkan Hub untuk mengikuti keadaan setiap zona. Demikian pula, setiap zona mengikuti keadaan Hub (tetapi zona jangan saling mengikuti kecuali secara tidak langsung melalui Pusat). Paket informasi kemudian dikomunikasikan dari satu zona ke zona lain dengan memasang bukti Merkle sebagai bukti bahwa informasi telah dikirim dan diterima. Mekanisme ini disebut komunikasi antar-blockchain, atau disingkat IBC. Zona mana pun dapat menjadi hub untuk membentuk grafik asiklik, namun demi kejelasan kami hanya akan menguraikan secara sederhana saja konfigurasi di mana hanya ada satu hub, dan banyak non-hub zona. Cosmos Hub adalah blockchain yang menampung multi-aset buku besar terdistribusi, di mana tokens dapat disimpan oleh pengguna individu atau berdasarkan zona itu sendiri. token ini dapat dipindahkan dari satu zona ke yang lain dalam paket IBC khusus yang disebut "paket koin". Hubnya adalah bertanggung jawab untuk menjaga invarian global dari total jumlah setiap token di seluruh zona. IBC paket koin transaksi harus dilakukan oleh pengirim, hub, dan penerima blockchains.Karena Cosmos Hub bertindak sebagai buku besar pusat untuk keseluruhan sistem, keamanan Hub adalah yang terpenting. Sementara setiap zona dapat berupa Tendermint blockchain yang diamankan dengan sebagai sedikitnya 4 (atau bahkan kurang jika konsensus BFT tidak diperlukan), Hub harus diamankan oleh serangkaian validator yang terdesentralisasi secara global dapat menahan skenario serangan yang paling parah, seperti a partisi jaringan kontinental atau serangan yang disponsori negara. Zona Cosmos adalah blockchain independen yang menukar IBC pesan dengan Hub. Dari perspektif Hub, zona adalah a akun multi-tanda tangan keanggotaan dinamis multi-aset itu dapat mengirim dan menerima tokens menggunakan paket IBC. Seperti a akun mata uang kripto, suatu zona tidak dapat mentransfer lebih dari tokens sudah, tetapi dapat menerima token dari orang lain yang memilikinya. Sebuah zona dapat ditetapkan sebagai "sumber" dari satu atau lebih jenis token, memberinya kekuatan untuk memasukkan pasokan token itu. Atom dari Cosmos Hub dapat dipertaruhkan oleh validators suatu zona terhubung ke hub. Sementara serangan double-spend terjadi di zona-zona tersebut akan mengakibatkan pemotongan atom dengan akuntabilitas Tendermint, sebuah zona di mana >⅔ hak suara berada Bizantium dapat melakukan status tidak valid. Hub Cosmos tidak memverifikasi atau mengeksekusi transaksi yang dilakukan di zona lain, demikianlah adanya tanggung jawab pengguna untuk mengirim tokens ke zona yang mereka percayai. Kedepannya, sistem tata kelola Hub Cosmos mungkin bisa melewati Hub proposal perbaikan yang memperhitungkan kegagalan zona. Untuk misalnya, transfer token keluar dari beberapa (atau semua) zona mungkin terjadi dibatasi untuk memungkinkan pemutusan sirkuit darurat pada zona (penghentian sementara transfer token) ketika serangan terdeteksi. Sekarang kita melihat bagaimana Hub dan zona berkomunikasi satu sama lain lainnya. Misalnya, jika ada tiga blockchain, “Zona1”, “Zona2”,

Cosmos hub and zones architecture showing the Cosmos Hub connecting multiple independent zones via IBC

dan "Hub", dan kami berharap "Zone1" menghasilkan paket tujuan untuk “Zona 2” melalui “Hub”. Untuk memindahkan paket dari satu blockchain ke yang lain, buktinya diposting di rantai penerima. Buktinya menyatakan bahwa rantai pengirim menerbitkan paket untuk dugaan tujuan. Agar rantai penerima dapat memeriksa bukti ini harus mampu mengikuti header blok pengirim. Ini mekanismenya mirip dengan yang digunakan oleh sidechains, yang membutuhkan dua rantai yang berinteraksi untuk menyadari satu sama lain melalui a aliran dua arah dari datagram bukti keberadaan (transaksi). Protokol IBC secara alami dapat didefinisikan menggunakan dua jenis transaksi: transaksi  IBCBlockCommitTx , yang memungkinkan a blockchain untuk membuktikan kepada pengamat mana pun tentang blok terbarunya-hash, dan transaksi IBCPacketTx , yang memungkinkan blockchain untuk buktikan kepada pengamat mana pun bahwa paket yang diberikan memang dipublikasikan melalui permohonan pengirim, melalui Merkle-proof hingga saat ini blok-hash. Dengan membagi mekanisme IBC menjadi dua transaksi terpisah, kami memungkinkan mekanisme pasar biaya asli dari rantai penerima menentukan paket mana yang dikomit (yaitu diakui), sementara memungkinkan kebebasan penuh pada rantai pengiriman tentang caranya banyak paket keluar diperbolehkan. Pada contoh di atas, untuk memperbarui blok-hash dari "Zona1" di “Hub” (atau “Hub” di “Zone2”), sebuah IBCBlockCommitTxtransaksi harus diposting di “Hub” dengan blok-hash dari “Zona1” (atau pada “Zona2” dengan blok-hash dari “Hub”). Lihat IBCBlockCommitTx dan IBCPacketTx untuk informasi lebih lanjut pada dua jenis transaksi IBC. Dengan cara yang sama Bitcoin lebih aman dengan menjadi terdistribusi, buku besar yang direplikasi secara massal, kita dapat membuat pertukaran menjadi lebih tidak rentan peretasan eksternal dan internal dengan menjalankannya di blockchain. Kami sebut ini pertukaran terdistribusi. Apa yang oleh komunitas cryptocurrency disebut sebagai desentralisasi pertukaran hari ini didasarkan pada sesuatu yang disebut transaksi “atomic crosschain” (AXC). Dengan transaksi AXC, dua pengguna aktif dua rantai yang berbeda dapat melakukan dua transaksi transfer itu dilakukan bersama-sama pada kedua buku besar, atau tidak sama sekali (mis. secara atomik). Misalnya, dua pengguna dapat memperdagangkan bitcoin dengan eter (atau dua token pada dua buku besar berbeda) menggunakan transaksi AXC, meskipun Bitcoin dan Ethereum tidak terhubung satu sama lain lainnya. Manfaat menjalankan pertukaran pada transaksi AXC adalah bahwa tidak ada pengguna yang perlu mempercayai satu sama lain atau melakukan pencocokan dagang layanan. Sisi negatifnya adalah kedua belah pihak harus online perdagangan yang akan terjadi. Jenis pertukaran terdesentralisasi lainnya adalah pertukaran yang direplikasi secara massal pertukaran terdistribusi yang berjalan sendiri blockchain. Pengguna aktif pertukaran semacam ini dapat mengirimkan pesanan batas dan mengubahnya komputer mati, dan perdagangan dapat dilakukan tanpa kehadiran pengguna daring. blockchain cocok dan menyelesaikan perdagangan atas nama dari pedagang.

التطبيقات

يمكن للبورصة المركزية إنشاء سجل أوامر عميق للحدود الأوامر وبالتالي جذب المزيد من المتداولين. السيولة تولد المزيد السيولة في عالم الصرف، وبالتالي هناك شبكة قوية التأثير (أو على الأقل الفائز يأخذ أكبر قدر من التأثير) في التبادل عمل. الزعيم الحالي لتبادل العملات المشفرة اليوم هو Poloniex بحجم تداول على مدار 24 ساعة بقيمة 20 مليون دولار، وفي المركز الثاني Bitynex بحجم تداول على مدار 24 ساعة بقيمة 5 ملايين دولار. ونظرا لهذه الشبكة القوية من غير المرجح أن تقوم البورصات اللامركزية القائمة على AXC بذلك الفوز بالحجم عبر البورصات المركزية. من أجل اللامركزية تبادل للتنافس مع تبادل مركزي، فإنه سوف تحتاج لدعم دفاتر الطلبات العميقة مع أوامر الحد. فقط موزعة التبادل على blockchain يمكن أن يوفر ذلك. يوفر Tendermint فوائد إضافية للمعاملات الأسرع يرتكب. من خلال إعطاء الأولوية للسرعة دون التضحية الاتساق، يمكن للمناطق الموجودة في Cosmos إجراء المعاملات بسرعة - من أجل كلاً من معاملات أوامر الصرف وكذلك IBC token التحويلات إلى ومن مناطق أخرى. بالنظر إلى حالة بورصات العملات المشفرة اليوم، يعد هذا أمرًا رائعًا تطبيق Cosmos هو التبادل الموزع (المعروف أيضًا باسم Cosmos ديكس). القدرة الإنتاجية للمعاملة كذلك يمكن أن يكون وقت استجابة الالتزام مشابهًا لتلك المركزية التبادلات. يمكن للمتداولين تقديم أوامر محددة يمكن تنفيذها دون أن يكون كلا الطرفين متصلين بالإنترنت. ومع تندرمينت، مركز Cosmos وIBC، يمكن للمتداولين نقل الأموال داخل وخارج التبادل من وإلى المناطق الأخرى بسرعة. يمكن أن تعمل المنطقة المميزة كمصدر لـ token من عملة مشفرة أخرى. الجسر يشبه العلاقة بين المركز والمنطقة Cosmos؛ كلاهما يجب أن يواكبا أحدث الكتل للآخر من أجل التحقق من الأدلة التي يمتلكها tokens انتقلت من واحدة إلى أخرى. "منطقة الجسر" على Cosmos تواكب الشبكة المحور بالإضافة إلى الآخر

عملة مشفرة. يسمح الاتجاه غير المباشر عبر منطقة الجسر منطق المحور ليظل بسيطًا ومحايدًا للآخرين blockchain إستراتيجيات الإجماع مثل Bitcoin proof-of-work التعدين. سيتم تشغيل كل منطقة جسر validator بواسطة Tendermint blockchain مع تطبيق جسر خاص ABCI، ولكن أيضًا عقدة كاملة لـ "الأصل" blockchain. عندما يتم استخراج كتل جديدة في الأصل، منطقة الجسر سوف يتوصل validators إلى اتفاق بشأن الكتل الملتزم بها من خلال التوقيع ومشاركة وجهة نظرهم المحلية الخاصة بالأصل blockchain نصيحة. عندما تتلقى منطقة الجسر الدفع على الأصل (و وقد تم الاتفاق على ما يكفي من التأكيدات في هذه القضية لسلسلة PoW مثل Ethereum أو Bitcoin)، المقابلة يتم إنشاء الحساب في منطقة الجسر بهذا الرصيد. في حالة Ethereum، يمكن لمنطقة الجسر مشاركة نفس الشيء validator-تم تعيينه كمركز Cosmos. على الجانب Ethereum ( Origin)، سيسمح عقد الجسر لحاملي الأثير بإرسال الأثير إلى منطقة الجسر عن طريق إرسالها إلى عقد الجسر Ethereum. بمجرد استلام الأثير من خلال عقد الجسر، فإن لا يمكن سحب الأثير إلا إذا كانت هناك حزمة IBC مناسبة تم استلامها بموجب عقد الجسر من منطقة الجسر. ال يتتبع عقد الجسر مجموعة validator لمنطقة الجسر، والتي قد تكون مطابقة لمجموعة Cosmos Hub validator. في حالة Bitcoin، المفهوم مشابه باستثناء أنه بدلاً من ذلك عقد جسر واحد، سيتم التحكم في كل UTXO بواسطة أ عتبة متعددة التوقيعات P2SH. بسبب القيود في نظام P2SH، لا يمكن أن يكون الموقعون متطابقين مع Cosmos المحور validator-مجموعة.يمكن نقل الأثير الموجود في منطقة الجسر ("الأثير الجسري") إلى ومن المحور، ويتم تدميرها لاحقًا بمعاملة ذلك يرسلها إلى عنوان سحب معين على Ethereum. IBC حزمة تثبت أن المعاملة حدثت في منطقة الجسر يمكن نشرها على عقد الجسر Ethereum للسماح بالأثير ليتم سحبها. في حالة Bitcoin، يقوم نظام البرمجة النصية المقيدة بذلك من الصعب عكس آلية نقل العملة IBC. كل UTXO لديه منشور مستقل خاص به، لذلك يجب أن يكون كل UTXO تم الترحيل إلى UTXO الجديد عندما يكون هناك تغيير في مجموعة Bitcoin موقعي الضمان. أحد الحلول هو الضغط و قم بفك ضغط مجموعة UTXO حسب الضرورة للحفاظ على العدد الإجمالي من UTXOs لأسفل. إن خطر مثل هذا العقد التجسيري هو مجموعة validator المارقة. ≥⅓ يمكن أن تتسبب قوة التصويت البيزنطية في حدوث شوكة وسحب الأثير من عقد الجسر على Ethereum مع الحفاظ على جسر الجسر في منطقة الجسر. والأسوأ من ذلك أن قوة التصويت البيزنطية يمكنها ذلك سرقة الأثير مباشرة من أولئك الذين أرسلوه إلى عقد الجسر بالانحراف عن منطق التجسير الأصلي لمنطقة الجسر. من الممكن معالجة هذه المشكلات من خلال تصميم الجسر مسؤولة تماما. على سبيل المثال، كافة الحزم IBC من المركز و الأصل، قد يتطلب الاعتراف من قبل منطقة الجسر في بهذه الطريقة يمكن أن تكون جميع التحولات الحكومية في منطقة الجسر يتم تحديها والتحقق منها بكفاءة سواء من خلال المركز أو الأصل عقد الجسر. يجب أن يسمح المركز والأصل لمنطقة الجسر validators بنشر الضمانات، وtoken عمليات النقل خارج يجب تأخير عقد الجسر (وفك الضمانات فترة طويلة بما فيه الكفاية) للسماح بأية تحديات مدققين مستقلين. نترك تصميم المواصفات و تنفيذ هذا النظام مفتوح كمستقبل Cosmos

مقترح التحسين، ليتم تمريره من خلال مركز Cosmos نظام الحكم. يعد حل مشكلة القياس مشكلة مفتوحة لـ Ethereum. حاليًا، تقوم عقد Ethereum بمعالجة كل معاملة و أيضا تخزين جميع الدول. وصلة. نظرًا لأن Tendermint يمكنها تنفيذ الكتل بشكل أسرع بكثير من Ethereum proof-of-work، EVM المناطق المدعومة بإجماع Tendermint و يمكن أن يوفر التشغيل على الأثير الجسري أداءً أعلى Ethereum blockchains. بالإضافة إلى ذلك، على الرغم من أن Cosmos Hub و IBC لا تسمح آليات الحزم بمنطق العقد التعسفي التنفيذ في حد ذاته، يمكن استخدامه لتنسيق حركات token بين Ethereum العقود الجاري تنفيذها في مناطق مختلفة، توفير أساس للتوسع token المتمركز حول Ethereum عبر مشاركة. تعمل مناطق Cosmos على تشغيل منطق التطبيق التعسفي، والذي تم تحديده عند بداية حياة المنطقة ويمكن تحديثها مع مرور الوقت من قبل الحكم. تسمح هذه القابلية للمناطق بـ Cosmos بمثابة جسور إلى العملات المشفرة الأخرى مثل Ethereum أو Bitcoin، كما أنه يسمح بمشتقات تلك blockchains، باستخدام نفس قاعدة التعليمات البرمجية ولكن مع مجموعة validator مختلفة و التوزيع الأولي. وهذا يسمح للعديد من العملات المشفرة الموجودة أطر العمل، مثل تلك الخاصة بـ Ethereum، وZerocash، وBitcoin، CryptoNote وما إلى ذلك، لاستخدامها مع Tendermint Core، وهو محرك توافقي عالي الأداء، على شبكة مشتركة، فتح فرصة هائلة للتشغيل البيني عبر المنصات. علاوة على ذلك، باعتباره أصلًا متعددًا blockchain، واحدًا قد تحتوي المعاملة على مدخلات ومخرجات متعددة، حيث يكون كل منها يمكن أن يكون الإدخال من أي نوع token، مما يتيح لـ Cosmos العمل مباشرةً كـ منصة للتبادل اللامركزي، على الرغم من افتراض الأوامرلتتم مطابقتها عبر منصات أخرى. بدلا من ذلك، يمكن للمنطقة أن تخدم كتبادل موزع متسامح مع الأخطاء (مع دفاتر الطلبات)، والذي يمكن أن يكون هناك تحسن صارم على المركزية الموجودة بورصات العملات المشفرة التي تميل إلى الاختراق مع مرور الوقت. يمكن أن تعمل المناطق أيضًا كإصدارات مدعومة من المؤسسة blockchain والأنظمة الحكومية، حيث أجزاء من خدمة معينة تدار تقليديا من قبل منظمة أو مجموعة من المنظمات يتم تشغيلها بدلاً من ذلك كتطبيق ABCI في منطقة معينة، والتي يسمح لها بوراثة الأمن وقابلية التشغيل البيني للجمهور Cosmos الشبكة دون التضحية بالتحكم في الشبكة الأساسية الخدمة. وبالتالي، قد يقدم Cosmos أفضل ما في العالمين المنظمات التي تتطلع إلى الاستفادة من تقنية blockchain ولكن من هي؟ الحذر من التخلي عن السيطرة بالكامل للثلث الموزع حزب. يدعي البعض أن هناك مشكلة كبيرة في تفضيل الاتساق خوارزميات الإجماع مثل Tendermint هي أن أي شبكة القسم الذي يتسبب في عدم وجود قسم واحد به >⅔ قوة التصويت (على سبيل المثال ≥⅓ الذهاب للخارج) ستوقف الإجماع تمامًا. يمكن أن تساعد بنية Cosmos في تخفيف هذه المشكلة باستخدام مركز عالمي مع مناطق الحكم الذاتي الإقليمية، حيث قوة التصويت لكل منطقة يتم توزيعها على أساس جغرافي مشترك المنطقة. على سبيل المثال، قد يكون النموذج المشترك للفرد المدن أو المناطق لتشغيل مناطقها الخاصة أثناء مشاركة أ المركز المشترك (على سبيل المثال، المركز Cosmos)، مما يتيح للنشاط البلدي تستمر في حالة توقف المحور بسبب شبكة مؤقتة التقسيم. لاحظ أن هذا يسمح بالجيولوجية والسياسية الحقيقية الميزات الطوبولوجية للشبكة التي يجب مراعاتها عند التصميم القوي الأنظمة الموحدة المتسامحة مع الأخطاء.

كانت NameCoin واحدة من أوائل blockchains التي حاولت حل مشكلة مشكلة تحليل الاسم عن طريق تكييف Bitcoin blockchain. لسوء الحظ كانت هناك العديد من المشاكل مع هذا النهج. باستخدام Namecoin، يمكننا التحقق من أن @satoshi، على سبيل المثال، كان كذلك مسجلة بمفتاح عام معين في وقت ما في الماضي، لكننا لا نعرف ما إذا كان المفتاح العام موجودًا منذ ذلك الحين تم تحديثه مؤخرًا ما لم نقم بتنزيل جميع الكتل منذ آخر مرة تحديث لهذا الاسم. ويرجع ذلك إلى القيود المفروضة على Bitcoin UTXO نموذج تحويل المعاملة Merkle، حيث فقط المعاملات (ولكن ليست حالة التطبيق القابلة للتغيير) هي من نوع Merkle في الكتلة-hash. وهذا يتيح لنا إثبات الوجود، ولكن ليس عدم وجود تحديثات لاحقة للاسم. وبالتالي، لا يمكننا أن نعرف تأكد من أحدث قيمة للاسم دون الثقة الكاملة العقدة، أو تكبد تكاليف كبيرة في النطاق الترددي عن طريق التنزيل كله blockchain. حتى لو تم تنفيذ شجرة بحث بحجم Merkle في NameCoin، اعتماده على proof-of-work يجعل عملية التحقق من العميل سهلة إشكالية. يجب على عملاء Light تنزيل نسخة كاملة من رؤوس جميع الكتل في blockchain بالكامل (أو على الأقل كل الرؤوس منذ آخر تحديث للاسم). وهذا يعني أن تتغير متطلبات عرض النطاق الترددي بشكل خطي مع مقدار الوقت [21]. بالإضافة إلى ذلك، يتغير الاسم على proof-of-work blockchain يتطلب انتظار كتل تأكيد إضافية proof-of-work، والذي يمكن أن يستغرق ما يصل إلى ساعة على Bitcoin. مع Tendermint، كل ما نحتاجه هو أحدث كتلة-hash موقعة من قبل نصاب قانوني قدره validators (بواسطة قوة التصويت)، وميركل دليل على القيمة الحالية المرتبطة بالاسم. هذا يجعلها من الممكن أن يكون لديك عميل خفيف مقتضب وسريع وآمن التحقق من قيم الاسم. في Cosmos، يمكننا أن نأخذ هذا المفهوم ونوسعه إلى أبعد من ذلك. كل يمكن أن تحتوي منطقة تسجيل الاسم في Cosmos على اسم نطاق المستوى الأعلى (TLD) مرتبط مثل ".com" أو ".org"، وكل اسم-

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

Aplikasi

Pertukaran terpusat dapat membuat buku batas yang dalam pesanan dan dengan demikian menarik lebih banyak pedagang. Likuiditas menghasilkan lebih banyak likuiditas di dunia bursa, sehingga terdapat jaringan yang kuat efek (atau setidaknya efek pemenang-ambil-terbanyak) dalam pertukaran bisnis. Pemimpin saat ini untuk pertukaran mata uang kripto saat ini adalah Poloniex dengan volume 24 jam sebesar $20 juta, dan di posisi kedua adalah Bitynex dengan volume 24 jam sebesar $5 juta. Mengingat jaringan yang begitu kuat Hal ini tidak mungkin terjadi pada bursa desentralisasi berbasis AXC memenangkan volume atas bursa terpusat. Untuk desentralisasi pertukaran untuk bersaing dengan pertukaran terpusat, hal ini diperlukan untuk mendukung buku pesanan mendalam dengan pesanan terbatas. Hanya didistribusikan pertukaran pada blockchain dapat menyediakannya. Tendermint memberikan manfaat tambahan berupa transaksi yang lebih cepat berkomitmen. Dengan mengedepankan ynalitas cepat tanpa berkorban konsistensi, zona di Cosmos dapat menginalisasi transaksi dengan cepat – untuk baik transaksi exchange order maupun IBC token transfer ke dan dari zona lain. Mengingat keadaan pertukaran mata uang kripto saat ini, bagus sekali aplikasi untuk Cosmos adalah pertukaran terdistribusi (alias the CosmosDEX). Kapasitas throughput transaksi juga latensi komit dapat dibandingkan dengan latensi terpusat pertukaran. Trader dapat mengirimkan limit order yang dapat dieksekusi tanpa kedua belah pihak harus online. Dan dengan Tendermint, hub Cosmos, dan IBC, pedagang dapat memindahkan dana masuk dan keluar pertukaran ke dan dari zona lain dengan cepat. Zona istimewa dapat bertindak sebagai sumber token yang dijembatani mata uang kripto lainnya. Sebuah jembatan mirip dengan hubungan antara hub dan zona Cosmos; keduanya harus mengikuti perkembangan tersebut blok terbaru dari yang lain untuk memverifikasi bukti yang dimiliki tokens berpindah dari satu ke yang lain. Sebuah "zona jembatan" di Cosmos jaringan mengikuti Hub dan juga yang lainnya

mata uang kripto. Arahan melalui zona jembatan memungkinkan logika Hub untuk tetap sederhana dan agnostik terhadap yang lain blockchain strategi konsensus seperti proof-of-work Bitcoin pertambangan. Setiap zona jembatan validator akan menjalankan Tendermint bertenaga blockchain dengan aplikasi jembatan ABCI khusus, tetapi juga node penuh “asal” blockchain. Ketika blok baru ditambang di titik asal, zona jembatan validators akan mencapai kesepakatan mengenai blok yang berkomitmen dengan penandatanganan dan berbagi pandangan lokal masing-masing tentang blockchain asal tip. Ketika zona jembatan menerima pembayaran pada zona asal (dan konfirmasi yang cukup disepakati telah terlihat dalam kasus ini dari rantai PoW seperti Ethereum atau Bitcoin), sesuai akun dibuat di zona jembatan dengan saldo itu. Dalam kasus Ethereum, zona jembatan dapat berbagi hal yang sama validator-ditetapkan sebagai Hub Cosmos. Di sisi Ethereum ( asal), kontrak jembatan akan memungkinkan pemegang eter mengirim eter ke zona jembatan dengan mengirimkannya ke kontrak jembatan Ethereum. Setelah eter diterima oleh kontrak jembatan, itu eter tidak dapat ditarik kecuali paket IBC yang sesuai tersedia diterima oleh kontrak jembatan dari zona jembatan. Itu kontrak jembatan melacak validator-set zona jembatan, yang mungkin identik dengan set validator Hub Cosmos. Dalam kasus Bitcoin, konsepnya serupa kecuali sebaliknya satu kontrak jembatan, masing-masing UTXO akan dikendalikan oleh a pubscript P2SH multitanda tangan ambang batas. Karena keterbatasan sistem P2SH, penandatangan tidak boleh sama dengan Cosmos Pusat validator-set.Eter di zona jembatan (“bridged-ether”) dapat ditransfer ke dan dari Hub, dan kemudian dimusnahkan dengan transaksi itu mengirimkannya ke alamat penarikan tertentu di Ethereum. Sebuah IBC paket membuktikan bahwa transaksi terjadi di zona jembatan dapat diposting ke kontrak jembatan Ethereum untuk mengizinkan eter untuk ditarik. Dalam kasus Bitcoin, sistem skrip terbatas membuatnya sulit untuk meniru mekanisme transfer koin IBC. Setiap UTXO memiliki pubscript independennya sendiri, jadi setiap UTXO harus memilikinya bermigrasi ke UTXO baru ketika ada perubahan pada kumpulan Bitcoin penandatangan escrow. Salah satu solusinya adalah dengan mengompres dan dekompresi set UTXO seperlunya untuk mempertahankan jumlah totalnya dari UTXO turun. Resiko dari kontrak yang menjembatani seperti itu adalah sebuah rangkaian validator yang nakal. ≥⅓ Kekuatan suara Bizantium dapat menyebabkan percabangan, penarikan eter dari kontrak jembatan pada Ethereum sambil menjaga jembatan di zona jembatan. Lebih buruk lagi, >⅔ kekuatan suara Bizantium bisa mencuri eter langsung dari mereka yang mengirimkannya ke kontrak jembatan dengan menyimpang dari logika jembatan asli zona jembatan. Permasalahan ini dapat diatasi dengan merancang jembatan tersebut benar-benar akuntabel. Misalnya semua paket IBC, dari hub dan asal usulnya, mungkin memerlukan pengakuan dari zona jembatan di dalamnya sedemikian rupa sehingga semua transisi keadaan pada zona jembatan dapat dilakukan ditantang dan diverifikasi secara efisien baik oleh pusat maupun asal kontrak jembatan. Hub dan asal harus mengizinkan validators zona jembatan untuk mengirimkan jaminan, dan token mentransfer keluar dari kontrak jembatan harus ditunda (dan pelepasan jaminan jangka waktu yang cukup lama) untuk memungkinkan adanya tantangan yang dapat dilakukan auditor independen. Kami meninggalkan desain spesifikasi dan implementasi sistem ini terbuka sebagai masa depan Cosmos

proposal perbaikan, untuk disahkan oleh Cosmos Hub sistem pemerintahan. Memecahkan masalah penskalaan adalah masalah terbuka untuk Ethereum. Saat ini, Ethereum node memproses setiap transaksi dan juga menyimpan semua negara bagian. link. Karena Tendermint dapat melakukan pemblokiran lebih cepat daripada Ethereum proof-of-work, EVM zona yang didukung oleh konsensus Tendermint dan beroperasi pada bridged-ether dapat memberikan kinerja yang lebih tinggi Ethereum blockchains. Selain itu, meskipun Cosmos Hub dan IBC mekanisme paket tidak mengizinkan logika kontrak sewenang-wenang eksekusi itu sendiri, dapat digunakan untuk mengoordinasikan token gerakan antara Ethereum kontrak yang berjalan di zona berbeda, memberikan landasan untuk penskalaan token-sentris Ethereum melalui pecahan. Cosmos zona menjalankan logika aplikasi sewenang-wenang, yang didefinisikan pada awal kehidupan zona dan berpotensi diperbarui dari waktu ke waktu oleh pemerintahan. Kelenturan seperti itu memungkinkan Cosmos zona untuk bertindak sebagai jembatan ke mata uang kripto lainnya seperti Ethereum atau Bitcoin, dan juga mengizinkan turunan dari blockchain tersebut, menggunakan basis kode yang sama tetapi dengan set validator yang berbeda dan distribusi awal. Hal ini memungkinkan banyak cryptocurrency yang ada kerangka kerja, seperti Ethereum, Zerocash, Bitcoin, CryptoNote dan seterusnya, untuk digunakan dengan Tendermint Core mesin konsensus kinerja yang lebih tinggi, pada jaringan umum, membuka peluang luar biasa untuk interoperabilitas di seluruh dunia platform. Selanjutnya, sebagai multi-aset blockchain, satu transaksi mungkin berisi beberapa input dan output, dimana masing-masing masukan dapat berupa jenis token apa pun, sehingga memungkinkan Cosmos berfungsi langsung sebagai sebuah platform untuk pertukaran terdesentralisasi, meskipun pesanan diasumsikanuntuk dicocokkan melalui platform lain. Sebagai alternatif, suatu zona dapat berfungsi sebagai pertukaran toleransi kesalahan terdistribusi (dengan buku pesanan), yang dapat menjadi perbaikan yang ketat dibandingkan sistem terpusat yang sudah ada pertukaran mata uang kripto yang cenderung diretas seiring waktu. Zona juga dapat berfungsi sebagai versi perusahaan yang didukung blockchain dan sistem pemerintahan, di mana bagian dari layanan tertentu itu secara tradisional dijalankan oleh suatu organisasi atau sekelompok organisasi malah dijalankan sebagai aplikasi ABCI di zona tertentu, yang mana memungkinkannya mewarisi keamanan dan interoperabilitas publik Cosmos jaringan tanpa mengorbankan kendali atas yang mendasarinya layanan. Oleh karena itu, Cosmos mungkin menawarkan yang terbaik dari kedua hal tersebut organisasi yang ingin memanfaatkan teknologi blockchain tetapi siapa yang memanfaatkannya berhati-hati dalam melepaskan kendali sepenuhnya kepada pihak ketiga yang didistribusikan pesta. Beberapa orang menyatakan bahwa masalah utama adalah mengutamakan konsistensi algoritma konsensus seperti Tendermint adalah jaringan apa pun partisi yang menyebabkan tidak ada satu partisi dengan >⅔ hak suara (misalnya ≥⅓ mematikan zine) akan menghentikan konsensus sama sekali. Arsitektur Cosmos dapat membantu mengurangi masalah ini dengan menggunakan sebuah pusat global dengan zona otonom regional, dimana hak untuk memilih untuk setiap zona didistribusikan berdasarkan kesamaan geografis wilayah. Misalnya, paradigma umum mungkin ditujukan untuk individu kota, atau wilayah, untuk mengoperasikan zona mereka sendiri sambil berbagi a hub umum (misalnya Hub Cosmos), memungkinkan aktivitas kota untuk melakukan hal tersebut bertahan jika hub berhenti karena jaringan sementara partisi. Perhatikan bahwa ini memungkinkan kondisi geologi, politik, dan fitur topologi jaringan yang harus dipertimbangkan dalam merancang yang kuat sistem toleransi kesalahan gabungan.

NameCoin adalah salah satu dari blockchain pertama yang mencoba menyelesaikan masalah ini masalah resolusi nama dengan mengadaptasi Bitcoin blockchain. Sayangnya ada beberapa masalah dengan pendekatan ini. Dengan Namecoin, kami dapat memverifikasi bahwa, misalnya, @satoshi adalah terdaftar dengan kunci publik tertentu di masa lalu, tapi kita tidak tahu apakah kunci publiknya sudah ada diperbarui baru-baru ini kecuali kami mengunduh semua blok sejak yang terakhir pembaruan nama itu. Hal ini disebabkan oleh keterbatasan Bitcoin UTXO transaksi model Merkle-isasi, dimana hanya transaksi (tetapi bukan status aplikasi yang dapat diubah) di-merkle ke dalam blok-hash. Hal ini memungkinkan kami membuktikan keberadaannya, namun bukan ketiadaan pembaruan nama di kemudian hari. Jadi, kita tidak bisa mengetahuinya yakin nilai terbaru dari sebuah nama tanpa mempercayai keseluruhannya node, atau menimbulkan biaya bandwidth yang signifikan dengan mengunduh keseluruhan blockchain. Meskipun pohon pencarian Merkle diterapkan di NameCoin, ketergantungannya pada proof-of-work membuat verifikasi klien menjadi ringan bermasalah. Klien ringan harus mengunduh salinan lengkapnya header untuk semua blok di seluruh blockchain (atau setidaknya seluruh header sejak pembaruan terakhir pada sebuah nama). Ini berarti bahwa kebutuhan bandwidth berskala linier dengan jumlah waktu [21]. Selain itu, perubahan nama pada proof-of-work blockchain perlu menunggu blok konfirmasi proof-of-work tambahan, yang dapat memakan waktu hingga satu jam pada Bitcoin. Dengan Tendermint, yang kita butuhkan hanyalah blok terbaru-hash ditandatangani oleh kuorum validators (berdasarkan hak suara), dan Merkle bukti nilai saat ini yang terkait dengan nama tersebut. Ini berhasil mungkin untuk memiliki klien ringan yang ringkas, cepat, dan aman verifikasi nilai nama. Di Cosmos, kita dapat mengambil konsep ini dan memperluasnya lebih jauh. Masing-masing zona pendaftaran nama di Cosmos dapat memiliki nama domain tingkat atas (TLD) terkait seperti “.com” atau “.org”, dan setiap nama-

zona registrasi dapat memiliki tata kelola dan registrasi sendiri aturan.

الحكم والاقتصاد

في حين أن Cosmos Hub عبارة عن دفتر أستاذ موزع متعدد الأصول، إلا أنه يوجد أصل خاص token يسمى الذرة. الذرات هي staking الوحيدة token للمركز Cosmos. الذرات هي رخصة لحاملها التصويت أو التحقق من الصحة أو التفويض إلى validators أخرى. مثل Ethereum الأثير، يمكن أيضًا استخدام الذرات لدفع رسوم المعاملات تخفيف البريد العشوائي. ذرات إنزاتيوناري إضافية ومعاملة كتلة تتم مكافأة الرسوم إلى validator والمفوضين الذين يفوضون ذلك validators. ويمكن استخدام معاملة  BurnAtomTx  لاسترداد أي منها مبلغ متناسب من tokens من المجمع الاحتياطي. التوزيع الأولي للذرة tokens و validators في سفر التكوين سيذهب إلى الجهات المانحة لجمع التبرعات Cosmos (75%)، الجهات المانحة الرئيسية (5%)، Cosmos مؤسسة الشبكة (10%)، وALL IN BITS, Inc (10%). ومن لحظة التكوين فصاعدًا، سوف يصبح ثلث إجمالي كمية الذرات سيتم مكافأتك للمستعبدين validator والمفوضين كل عام. راجع خطة Cosmos للحصول على تفاصيل إضافية. على عكس Bitcoin أو غيره من proof-of-work blockchains، فإن Tendermint blockchain يصبح أبطأ مع المزيد من validators بسبب الزيادة تعقيد الاتصالات. ولحسن الحظ، يمكننا دعم ما يكفي validators لإنشاء blockchain قوي وموزع عالميًا مع أوقات تأكيد المعاملات السريعة جدًا، وعرض النطاق الترددي،

التخزين، وزيادة سعة الحوسبة الموازية، سنكون قادرين لدعم المزيد من validators في المستقبل. في يوم التكوين، سيتم تعيين الحد الأقصى لعدد validators إلى 100، وسيزداد هذا العدد بمعدل 13% لمدة 10 سنوات، و استقر عند 300 validators. يمكن لحاملي الذرة الذين ليسوا بالفعل أن يصبحوا validators بحلول التوقيع على معاملة  BondTx وإرسالها. كمية الذرات المقدمة كضمان يجب أن تكون غير صفرية. يمكن لأي شخص أن يصبح validator في أي وقت، إلا عندما يكون حجم التيار مجموعة validator أكبر من الحد الأقصى لعدد validators مسموح به. في هذه الحالة، تكون المعاملة صالحة فقط إذا كان المبلغ الذرات أكبر من كمية الذرات الفعالة التي يحتفظ بها الأصغر validator، حيث تشمل الذرات الفعالة الذرات المفوضة. عندما يحل validator الجديد محل validator الحالي بهذه الطريقة، validator الموجود يصبح غير نشط وجميع الذرات و تدخل الذرات المفوضة إلى حالة فك الارتباط. يجب أن يتم فرض بعض العقوبات على validators لأي منها الانحراف المقصود أو غير المقصود عن العقوبة البروتوكول. يتم قبول بعض الأدلة على الفور، مثل أ علامة مزدوجة على نفس الارتفاع والدائرية، أو انتهاكا السنة 0: 100  السنة الأولى: 113  السنة الثانية: 127  السنة 3: 144  السنة الرابعة: 163  السنة 5: 184  السنة 6: 208  السنة 7: 235  السنة 8: 265  السنة 9: 300  السنة 10: 300  ...

"prevote-the-lock" (قاعدة من بروتوكول إجماع Tendermint). سيؤدي مثل هذا الدليل إلى فقدان validator لوضعه الجيد وذراتها المرتبطة بالإضافة إلى حصتها التناسبية البالغة tokens في سيتم تخفيض مجموع الاحتياطي - الذي يطلق عليه مجتمعًا "حصته" -. في بعض الأحيان، لن يكون validators متاحًا، إما بسبب المنطقة انقطاع الشبكة أو انقطاع التيار الكهربائي أو لأسباب أخرى. إذا، في أي نقطة في كتل  ValidatorTimeoutWindow  السابقة، validator لم يتم تضمين التصويت الالتزام في blockchain أكثر من  مرات ValidatorTimeoutMaxAbsent، سيصبح validator غير نشط، وتفقد  ValidatorTimeoutPenalty  (الافتراضي 1%) من قيمته حصة. بعض السلوكيات "الخبيثة" لا يمكن تمييزها بشكل واضح الأدلة على blockchain. في هذه الحالات، يمكن لـ validators التنسيق خارج النطاق لفرض انتهاء مهلة هذه البرامج الضارة validators، إذا كان هناك إجماع بأغلبية ساحقة. في المواقف التي يتوقف فيها Cosmos Hub بسبب تحالف ≥⅓ من تختفي قوة التصويت، أو في الحالات التي يكون فيها ائتلاف ≥⅓ دليل رقابي على قوة التصويت على السلوك الخبيث من عند إدخال blockchain، يجب أن يتعافى المحور باستخدام شوكة صلبة اقتراح إعادة التنظيم. (رابط إلى "هجمات الشوكات والرقابة"). Cosmos يمكن للمحور validators قبول أي نوع أو مجموعة token أنواعها كرسوم معالجة معاملة. كل validator يمكن قم بتعيين سعر الصرف الذي تريده بشكل شخصي، ثم اختر مهما كانت المعاملات التي تريدها، طالما أن  BlockGasLimit  هو كذلك لم يتم تجاوزها. الرسوم المحصلة، ناقص أي ضرائب محددة أدناه، يتم إعادة توزيعها على أصحاب المصلحة المستعبدين بما يتناسب مع ذراتها المرتبطة، كل  ValidatorPayoutPeriod  (الافتراضي 1 ساعة).من بين رسوم المعاملات المحصلة، سيتم تطبيق  ReserveTax (الافتراضي 2%) اذهب نحو تجمع الاحتياطي لزيادة تجمع الاحتياطي و زيادة أمان وقيمة شبكة Cosmos. هذه ويمكن أيضًا توزيع الأموال وفقًا للقرارات صنعها نظام الحكم. أصحاب الذرة الذين يفوضون سلطة التصويت الخاصة بهم إلى validators آخرين دفع عمولة للمفوض validator. يمكن للجنة يتم تعيينها بواسطة كل validator. يعد أمان Cosmos Hub إحدى وظائف أمان validators واختيار التفويض من قبل المفوضين. من أجل تشجيع الاكتشاف والإبلاغ المبكر عما تم العثور عليه الثغرات الأمنية، يشجع مركز Cosmos المتسللين على النشر عمليات استغلال ناجحة عبر معاملة  ReportHackTx  التي تنص على أن "هذا تم اختراق validator. من فضلك أرسل المكافأة إلى هذا العنوان". على مثل هذا الاستغلال، سيصبح validator والمفوضون غير نشطين،  HackPunishmentRatio (الافتراضي 5%) من ذرات الجميع سيحصلون عليها مقطوعة، و  HackRewardRatio  (افتراضي 5%) من ذرات الجميع سوف تحصل على مكافأة على عنوان مكافأة المتسلل. validator يجب استعادة الذرات المتبقية باستخدام مفتاح النسخ الاحتياطي الخاص بهم. من أجل منع إساءة استخدام هذه الميزة للنقل الذرات غير المكتسبة، جزء من الذرات المكتسبة مقابل الذرات غير المكتسبة validators والمفوضون قبل وبعد  ReportHackTx  سوف تظل كما هي، وستتضمن مكافأة الهاكر بعضًا منها الذرات غير المستثمرة، إن وجدت. يتم تشغيل مركز Cosmos بواسطة مؤسسة موزعة يتطلب آلية حوكمة جيدة التصميم من أجل تنسيق التغييرات المختلفة على blockchain، مثل المتغير

معلمات النظام، بالإضافة إلى ترقيات البرامج و التعديلات الدستورية. جميع validator مسؤولون عن التصويت على جميع المقترحات. الفشل في سيؤدي التصويت على الاقتراح في الوقت المناسب إلى validator يتم إلغاء التنشيط تلقائيًا لفترة من الوقت تسمى  عقوبة الغياب  (أسبوع واحد افتراضيًا). يرث المفوضون صوت المفوض تلقائيًا validator. قد يتم تجاوز هذا التصويت يدويًا. الذرات غير المرتبطة لا تحصل على أي تصويت. يتطلب كل اقتراح إيداع مبلغ MinimumProposalDeposit  tokens، والتي قد تكون مزيجًا من واحد أو أكثر من tokens بما في ذلك الذرات. بالنسبة لكل اقتراح، يجوز للناخبين التصويت لاتخاذه الوديعة. إذا اختار أكثر من نصف الناخبين التصويت الإيداع (على سبيل المثال، لأن الاقتراح كان غير مرغوب فيه)، يذهب الإيداع إلى المجمع الاحتياطي، باستثناء أي ذرات يتم حرقها. لكل مقترح، يمكن للناخبين التصويت بالخيارات التالية: نعم نعم مع القوة كلا NayWithForce امتنع عن التصويت أغلبية صارمة من أصوات نعم أو YeaWithForce (أو لا أو أصوات NayWithForce) مطلوبة حتى يتم تحديد الاقتراح تم إقراره (أو تقرر فشله)، ولكن يمكن لـ 1/3+ استخدام حق النقض ضد الأغلبية القرار بالتصويت "بالقوة". عندما يتم نقض الأغلبية الصارمة، تتم معاقبة الجميع بخسارة  VetoPenaltyFeeBlocks  (قيمة افتراضية للكتل ليوم واحد) بقيمة الرسوم (باستثناء الضرائب والتي لن تتأثر)، والحزب الذي اعترض على الأغلبية

ستتم معاقبة القرار أيضًا بخسارة  VetoPenaltyAtoms  (الافتراضي 0.1%) من ذراته. يمكن تغيير أي من المعلمات المحددة هنا باستخدام تمرير  ParameterChangeProposal. يمكن تجميد الذرات واحتجاز أموال المجمع التي يتم إنفاقها باستخدام تمرير  اقتراح المكافأة. جميع المقترحات الأخرى، مثل اقتراح ترقية البروتوكول، سيتم تنسيقه عبر  TextProposal  العام. انظر الخطة. لقد كان هناك العديد من الابتكارات في إجماع blockchain و قابلية التوسع في العامين الماضيين. يقدم هذا القسم نبذة مختصرة مسح لعدد مختار من المهم. الإجماع في وجود مشاركين خبيثين يمثل مشكلة يعود تاريخها إلى أوائل الثمانينيات، عندما صاغ ليزلي لامبورت عبارة "خطأ بيزنطي" للإشارة إلى سلوك العملية التعسفية ينحرف عن السلوك المقصود، على عكس "خطأ التصادم"، حيث تتعطل العملية ببساطة. تم اكتشاف الحلول المبكرة للشبكات المتزامنة حيث يوجد حد أعلىزمن وصول الرسالة، على الرغم من أن الاستخدام العملي كان يقتصر على درجة عالية البيئات الخاضعة للرقابة مثل وحدات التحكم في الطائرات و مراكز البيانات متزامنة عبر الساعات الذرية. ولم يكن حتى أواخر التسعينيات أن التسامح مع الخطأ البيزنطي العملي (PBFT) [11] كان تم تقديمه كإجماع متزامن فعال جزئيًا خوارزمية قادرة على تحمل ما يصل إلى ثلث العمليات التي تتصرف تعسفا. أصبحت PBFT هي الخوارزمية القياسية، مما أدى إلى ظهور العديد منها الاختلافات، بما في ذلك أحدثها التي تم إنشاؤها بواسطة IBM كجزء من مساهمتهم في Hyperledger. الميزة الرئيسية لإجماع Tendermint على PBFT هي ذلك يحتوي Tendermint على بنية أساسية محسنة ومبسطة، بعضها نتيجة لتبني نموذج blockchain. يجب أن تلتزم كتل Tendermint بالترتيب، مما يتجنب التعقيد وحمل الاتصالات المرتبط بـ PBFT تغييرات العرض. في Cosmos والعديد من العملات المشفرة، لا يوجد بحاجة إلى السماح للكتلة N+i حيث i >= 1 بالالتزام، عند الكتلة N نفسها لم تلتزم بعد. إذا كان عرض النطاق الترددي هو السبب وراء حظر N لم يتم الالتزام به في منطقة Cosmos، فلا يساعد في الاستخدام أصوات مشاركة النطاق الترددي للكتل N+i. إذا كان قسم الشبكة أو عقد ofzine هي السبب وراء عدم التزام الكتلة N N + لن ألتزم على أي حال. بالإضافة إلى ذلك، فإن تجميع المعاملات في كتل يسمح بذلك Merkle-hashing العادي لحالة التطبيق، بدلاً من الملخصات الدورية كما هو الحال مع مخطط نقاط التفتيش PBFT. هذا يسمح من أجل تنفيذ معاملات أسرع يمكن إثباتها للعملاء الخفيفين وبشكل أسرع التواصل بين blockchain. يتضمن Tendermint Core أيضًا العديد من التحسينات والميزات التي تتجاوز ما هو محدد في PBFT. على سبيل المثال، يتم تقسيم الكتل المقترحة بواسطة validators إلى أجزاء، بحجم Merkle، والنميمة بطريقة تعمل على تحسين البث الأداء (راجع LibSwift [19] للإلهام). أيضا، تندرمينت لا يقدم Core أي افتراضات حول نقطة إلى نقطة

الاتصال والوظائف طالما أن شبكة P2P موجودة متصلة بشكل ضعيف. على الرغم من أنها ليست أول من نشر proof-of-stake (PoS)، إلا أن BitShares1.0 [12] ساهم بشكل كبير في البحث واعتماد إثبات الحصة (PoS). blockchains، وخاصة تلك المعروفة باسم نقاط البيع "المفوضة". في BitShares، أصحاب المصلحة ينتخبون "الشهود"، المسؤولين عن الطلب وارتكاب المعاملات و"المندوبين" المسؤولين عنها تنسيق تحديثات البرامج وتغييرات المعلمات. يهدف BitShares2.0 إلى تحقيق أداء عالي (100k tx/s, 1s الكمون) في ظروف مثالية، مع كل كتلة موقعة من قبل واحد المُوقع، وتستغرق عملية المعاملة وقتًا أطول قليلاً من الفاصل الزمني للكتلة. لا تزال المواصفات الأساسية قيد التطوير. يمكن لأصحاب المصلحة إزالة أو استبدال الشهود الذين يسيئون التصرف على بشكل يومي، ولكن لا يوجد ضمانات هامة من الشهود أو المندوبون على غرار Tendermint PoS الذين تم اقتطاعهم حالة نجاح هجوم الإنفاق المزدوج. بناءً على النهج الذي ابتكرته شركة Ripple، Stellar [13] رينيد أ نموذج للاتفاقية البيزنطية الموحدة حيث تتم العمليات المشاركة في الإجماع لا تشكل yxed وعالميا مجموعة معروفة. بدلاً من ذلك، تقوم كل عقدة عملية برعاية واحدة أو أكثر "شرائح النصاب"، يشكل كل منها مجموعة من العمليات الموثوقة. أ "النصاب القانوني" في Stellar مصمم ليكون مجموعة من العقد التي تحتوي على شريحة نصاب واحدة على الأقل لكل عقدة في المجموعة، بحيث يمكن التوصل إلى اتفاق. يعتمد أمان آلية Stellar على الافتراض أن تقاطع أي نصابين غير فارغ، في حين أن يتطلب توفر العقدة شريحة واحدة على الأقل من شرائح النصاب القانوني الخاصة بها تتكون بالكامل من العقد الصحيحة، مما يخلق مفاضلة بين استخدام شرائح النصاب الكبيرة أو الصغيرة التي قد يكون من الصعب تحقيق التوازن فيها دون فرض افتراضات هامة حول الثقة. أخيرًا،يجب أن تختار العقد بطريقة أو بأخرى شرائح النصاب القانوني المناسبة لذلك أن يكون كافيًا للتسامح مع الأخطاء (أو أي "عقد سليمة" على الإطلاق، منها الكثير من نتائج الورقة تعتمد على)، والوحيد الإستراتيجية المقدمة لضمان مثل هذا التكوين هي تسلسل هرمي وهو مشابه لبروتوكول بوابة الحدود (BGP)، الذي يستخدمه مزودو خدمة الإنترنت من الدرجة الأولى على الإنترنت لإنشاء جداول التوجيه العالمية، ومن خلال التي تستخدمها المتصفحات لإدارة شهادات TLS؛ كلاهما سيئ السمعة لانعدام الأمن لديهم. تم تخفيف الانتقادات الواردة في ورقة Stellar الخاصة بأنظمة إثبات الملكية القائمة على Tendermint من خلال استراتيجية token الموضحة هنا، حيث يتم إصدار نوع جديد من token يسمى الذرة تمثل المطالبات بالأجزاء المستقبلية من الرسوم والمكافآت. ال إن ميزة proof-of-stake المستندة إلى Tendermint هي قريبها البساطة، مع الاستمرار في توفير الأمان الكافي والقابل للإثبات الضمانات. BitcoinNG هو تحسين مقترح لـ Bitcoin من شأنه أن يسمح لأشكال قابلية التوسع الرأسي، مثل زيادة حجم الكتلة، دون العواقب الاقتصادية السلبية المرتبطة عادة مع مثل هذا التغيير، مثل التأثير الكبير بشكل غير متناسب على عمال المناجم الصغيرة. ويتحقق هذا التحسن عن طريق الانفصال انتخاب القائد من بث المعاملات: القادة هم الأولون تم انتخابه بواسطة proof-of-work في "الكتل الصغيرة"، ثم أصبح قادرًا على ذلك يجب الالتزام بمعاملات البث حتى يتم إنشاء كتلة صغيرة جديدة تم العثور عليه. وهذا يقلل من متطلبات عرض النطاق الترددي اللازمة ل الفوز بسباق إثبات العمل (PoW)، مما يسمح لصغار عمال المناجم بالمنافسة بشكل أكثر عدالة، والسماح بإجراء المعاملات بشكل أكثر انتظامًا بواسطة آخر عامل منجم يعثر على كتلة صغيرة. Casper [16] عبارة عن خوارزمية إجماع proof-of-stake مقترحة لـ Ethereum. أسلوب عملها الأساسي هو "الإجماع على الرهان". بواسطة السماح لـ validators بالمراهنة بشكل متكرر على الكتلة التي يعتقدون أنها ستفعل

تصبح ملتزمًا بـ blockchain بناءً على الرهانات الأخرى كما رأوه حتى الآن، يمكن تحقيق النزعة الجنسية في نهاية المطاف. وصلة. يعد هذا مجال بحث نشط بواسطة فريق Casper. ال التحدي يكمن في بناء آلية الرهان التي يمكن أن تكون ثبت أنها استراتيجية مستقرة تطوريا. الفائدة الرئيسية من قد يكون Casper مقارنةً بـ Tendermint في تقديم "التوافر". "على الاتساق" - لا يتطلب الإجماع أكثر من ⅔ النصاب القانوني قوة التصويت - ربما على حساب سرعة الالتزام أو تعقيد التنفيذ. لا يعد بروتوكول Interledger [14] حلاً قابلاً للتوسع بشكل صارم. ذلك يوفر التشغيل البيني المخصص بين دفاتر الأستاذ المختلفة الأنظمة من خلال شبكة علاقات ثنائية مترابطة بشكل فضفاض. مثل شبكة Lightning Network، فإن الغرض من ILP هو التسهيل المدفوعات، لكنه يركز بشكل خاص على المدفوعات عبر متباينة أنواع دفتر الأستاذ، وتمتد آلية المعاملات الذرية إلى لا تتضمن فقط hash-الأقفال، ولكن أيضًا النصاب القانوني لكتاب العدل (يسمى بروتوكول النقل الذري). الآلية الأخيرة ل إن فرض الذرية في المعاملات بين دفاتر الأستاذ يشبه آلية SPV العميلة الخفيفة الخاصة بـ Tendermint، مثال توضيحي لـ التمييز بين ILP و Cosmos/IBC أمر مضمون، و المنصوص عليها أدناه. 1. لا يدعم كتاب العدل للموصل في ILP العضوية التغييرات، ولا تسمح بالترجيح بين كتاب العدل. من ناحية أخرى، تم تصميم IBC خصيصًا لـ blockchains، حيث يمكن أن يكون لـ validators أوزان مختلفة، و حيث يمكن أن تتغير العضوية على مدار blockchain. 2. كما هو الحال في Lightning Network، متلقي الدفع في ILP يجب أن يكون متصلاً بالإنترنت لإرسال رسالة تأكيد إلى المرسل. في أtoken نقل عبر IBC، مجموعة validator لجهاز الاستقبال blockchain هو المسؤول عن توفير التأكيد، وليس استقبال المستخدم. 3. الفرق الأكثر لفتًا للانتباه هو أن موصلات ILP ليست كذلك مسؤولاً أو يحتفظ بحالة موثوقة بشأن المدفوعات، بينما في Cosmos، validators للمحور هي سلطة حالة IBC token عمليات النقل بالإضافة إلى سلطة كمية tokens التي تحتفظ بها كل منطقة (ولكن ليس مقدار tokens التي يحتفظ بها كل حساب داخل المنطقة). هذا هو الابتكار الأساسي الذي يسمح بأمان غير متماثل نقل tokens من منطقة إلى أخرى؛ التناظرية لـ ILP الموصل في Cosmos هو موصل ثابت وآمن إلى أقصى حد blockchain دفتر الأستاذ، مركز Cosmos. 4. يجب أن تكون المدفوعات بين دفاتر الأستاذ في ILP مدعومة بـ دفتر أوامر الصرف، حيث لا يوجد نقل غير متماثل لـ عملات معدنية من دفتر أستاذ إلى آخر، فقط نقل القيمة أو معادلات السوق. السلاسل الجانبية [15] هي آلية مقترحة لتوسيع نطاق Bitcoin الشبكة عبر blockchains البديلة "المرتبطة في اتجاهين". Bitcoin blockchain. (الربط في اتجاهين يعادل التجسير. في Cosmos نقول "جسر" للتمييز عن ربط السوق). تسمح السلاسل الجانبية لعملات البيتكوين بالانتقال بشكل فعال من Bitcoin blockchain إلى السلسلة الجانبية والظهر، والسماح بـ تجربة الميزات الجديدة على السلسلة الجانبية. كما في Cosmos Hub والسلسلة الجانبية وBitcoin بمثابة عملاء خفيفين لـ بعضها البعض، باستخدام أدلة SPV لتحديد متى يجب أن تكون العملات المعدنية نقل إلى Sidechain والعودة. بالطبع منذ Bitcoin الاستخدامات proof-of-work، تعاني السلاسل الجانبية المتمركزة حول Bitcoin من مشاكل ومخاطر proof-of-work العديدة كما أ آلية الإجماع. علاوة على ذلك، هذا هو الحد الأقصى Bitcoin الحل الذي لا يدعم أصلاً مجموعة متنوعة من tokens و

طوبولوجيا الشبكة بين المناطق كما يفعل Cosmos. وقيل: جوهر آلية الربط في الاتجاهين هي من حيث المبدأ نفس تلك الآلية يعمل لدى شبكة Cosmos. يقوم Ethereum حاليًا بالبحث في عدد من الاستراتيجيات المختلفة لتقسيم حالة Ethereum blockchain لمعالجة احتياجات قابلية التوسع. وتهدف هذه الجهود إلى الحفاظ على طبقة التجريد التي تقدمها الآلة الافتراضية Ethereum الحالية عبر مساحة الدولة المشتركة. الجهود البحثية المتعددة هي الجارية في هذا الوقت. [18][22] Cosmos وEthereum 2.0 بنفسجي [22] لهما أهداف تصميمية مختلفة. Cosmos يتعلق بشكل خاص بـ tokens. البنفسجي يدور حول القياس الحساب العام. Cosmos غير مرتبط بـ EVM، لذلك يمكن حتى للأجهزة الافتراضية المختلفة التفاعل. Cosmos يتيح لمنشئ المنطقة تحديد من يقوم بالتحقق من صحة المنطقة. يمكن لأي شخص أن يبدأ منطقة جديدة في Cosmos (ما لم تكن الإدارة يقرر خلاف ذلك). يقوم المحور بعزل حالات فشل المنطقة بحيث تكون الثوابت العالمية token كذلك محفوظ. الشبكة المسرّعة هي شبكة نقل مقترحة token تعمل في طبقة أعلى Bitcoin blockchain (وغيرها من الطبقات العامة blockchains)، مما يتيح تحسين العديد من أوامر الحجم في إنتاجية المعاملات عن طريق نقل غالبية المعاملات خارج دفتر الأستاذ الإجماعي إلى ما يسمى "قنوات الدفع".أصبح هذا ممكنًا بفضل البرامج النصية للعملات المشفرة الموجودة على السلسلة، والتي تمكين الأطراف من الدخول في عقود ثنائية الحالة حيث يمكن تحديث الحالة من خلال مشاركة التوقيعات الرقمية والعقود يمكن إغلاقه عن طريق نشر الأدلة بشكل صريح على blockchain، أ الآلية التي تم نشرها لأول مرة عن طريق المقايضة الذرية عبر السلسلة. بواسطة فتح قنوات الدفع مع العديد من الأطراف والمشاركين في يمكن أن تصبح الشبكة المسرّعة نقاطًا محورية لتوجيه الشبكة مدفوعات الآخرين، مما يؤدي إلى قناة دفع متصلة بالكامل الشبكة، على حساب رأس المال الذي يتم ربطه بقنوات الدفع. بينما يمكن للشبكة المسرّعة أيضًا أن تمتد بسهولة عبرها عدة blockchains مستقلة للسماح بنقل القيمة عبر سوق الصرف، لا يمكن استخدامه بشكل غير متماثل نقل tokens من blockchain إلى آخر. الفائدة الرئيسية الغرض من شبكة Cosmos الموصوفة هنا هو تمكين هذا التوجيه المباشر token التحويلات. ومع ذلك، فإننا نتوقع قنوات الدفع و سيتم اعتماد شبكة Lightning Network على نطاق واسع جنبًا إلى جنب مع شبكتنا token آلية النقل، لتوفير التكاليف ولأسباب تتعلق بالخصوصية. الشاهد المنفصل هو رابط مقترح تحسين Bitcoin يهدف إلى زيادة إنتاجية المعاملات لكل كتلة 2X أو 3X، مع جعل مزامنة الكتلة أسرع للعقد الجديدة في نفس الوقت. يكمن تألق هذا الحل في كيفية عمله داخل قيود بروتوكول Bitcoin الحالي وتسمح بالشوكة الناعمة الترقية (أي أن العملاء الذين لديهم إصدارات أقدم من البرنامج سوف يقومون بذلك الاستمرار في العمل بعد الترقية). تندرمينت، كونها جديدة البروتوكول ليس له قيود على التصميم، لذلك له مقياس مختلف الأولويات. في المقام الأول، يستخدم Tendermint خوارزمية BFT المستديرة على أساس التوقيعات التشفير بدلا من التعدين، والتي يسمح بشكل تافه بالتحجيم الأفقي من خلال التوازي المتعدد blockchains، بينما تسمح عمليات الحظر المنتظمة والمتكررة بذلك التحجيم العمودي كذلك.

Pemerintahan dan Ekonomi

Meskipun Cosmos Hub adalah buku besar yang didistribusikan multi-aset, namun ada token asli khusus yang disebut atom. Atom adalah satu-satunya staking token dari Pusat Cosmos. Atom adalah lisensi bagi pemegangnya memilih, memvalidasi, atau mendelegasikan ke validator lainnya. Suka Ethereum eter, atom juga dapat digunakan untuk membayar biaya transaksi mengurangi spam. Atom inzationary tambahan dan transaksi blok biaya diberikan kepada validators dan delegator yang mendelegasikannya validatordtk. Transaksi  BurnAtomTx  dapat digunakan untuk memulihkan apa pun jumlah proporsional tokens dari kumpulan cadangan. Distribusi awal atom tokens dan validators di Genesis akan diberikan kepada donatur Cosmos Penggalangan Dana (75%), donatur utama (5%), Cosmos Network Foundation (10%), dan ALL IN BITS, Inc (10%). Sejak awal mula, 1/3 dari jumlah total atom akan terbentuk diberikan penghargaan kepada validator dan delegasi yang terikat setiap tahun. Lihat Paket Cosmos untuk detail tambahan. Berbeda dengan Bitcoin atau proof-of-work blockchain lainnya, Tendermint blockchain menjadi lebih lambat dengan lebih banyak validator karena peningkatan kompleksitas komunikasi. Untungnya, kami dapat mendukung cukup validators untuk menghasilkan blockchain yang kuat dan terdistribusi secara global dengan waktu konfirmasi transaksi yang sangat cepat, dan, sebagai bandwidth,

penyimpanan, dan peningkatan kapasitas komputasi paralel, kita akan mampu untuk mendukung lebih banyak validator di masa depan. Pada hari asal, jumlah maksimum validator akan ditetapkan ke 100, dan jumlah ini akan meningkat pada tingkat 13% selama 10 tahun, dan menetap pada 300 validators. Pemegang atom yang belum dapat menjadi validators pada saat itu menandatangani dan mengirimkan transaksi  BondTx . Jumlah atom yang diberikan sebagai jaminan harus bukan nol. Siapa pun bisa menjadi a validator kapan saja, kecuali besarnya arus validator set lebih besar dari jumlah maksimum validators diperbolehkan. Dalam hal ini, transaksi hanya sah jika jumlahnya atom lebih besar dari jumlah atom efektif yang ditahan oleh validator terkecil, di mana atom efektif mencakup atom yang didelegasikan. Ketika validator baru menggantikan validator yang sudah ada sedemikian rupa, validator yang ada menjadi tidak aktif dan semua atom dan atom yang didelegasikan memasuki keadaan tidak terikat. Pasti ada penalti yang dikenakan pada validator untuk siapa pun penyimpangan yang disengaja atau tidak disengaja dari sanksi protokol. Beberapa bukti dapat langsung diterima, seperti a tanda ganda pada ketinggian dan putaran yang sama, atau pelanggaran Tahun 0: 100  Tahun 1: 113  Tahun 2: 127  Tahun 3: 144  Tahun 4: 163  Tahun 5: 184  Tahun 6: 208  Tahun 7: 235  Tahun 8: 265  Tahun 9: 300  Tahun 10: 300  ...

“prevote-the-lock” (aturan protokol konsensus Tendermint). Bukti tersebut akan mengakibatkan validator kehilangan reputasi baiknya dan atom-atom yang terikat serta bagian proporsionalnya sebesar tokens di kumpulan cadangan – yang secara kolektif disebut “saham” – akan dipangkas. Terkadang, validators tidak tersedia, karena faktor regional gangguan jaringan, kegagalan daya, atau alasan lainnya. Jika, kapan saja titik di blok  ValidatorTimeoutWindow  yang lalu, validator melakukan suara tidak termasuk dalam blockchain lebih dari  ValidatorTimeoutMaxAbsent  kali, maka validator akan menjadi tidak aktif, dan kehilangan  ValidatorTimeoutPenalty  (DEFAULT 1%) darinya taruhan. Beberapa perilaku “jahat” tidak menghasilkan hasil yang terlihat jelas bukti di blockchain. Dalam kasus ini, validator bisa berkoordinasi di luar band untuk memaksa batas waktu bagi orang-orang jahat ini validators, jika terdapat konsensus super mayoritas. Dalam situasi di mana Hub Cosmos terhenti karena ≥⅓ koalisi hak suara terjadi di zine, atau dalam situasi di mana terdapat ≥⅓ koalisi hak suara menyensor bukti perilaku jahat dari memasuki blockchain, hub harus pulih dengan hard-fork proposal ulang. (Tautan ke “Serangan Garpu dan Sensor”). Cosmos Hub validators dapat menerima jenis atau kombinasi token apa pun jenis sebagai biaya untuk memproses transaksi. Setiap validator kaleng secara subyektif menetapkan nilai tukar apa pun yang diinginkannya, dan memilih transaksi apa pun yang diinginkannya, selama  BlockGasLimit  ada tidak terlampaui. Biaya yang dipungut, dikurangi pajak apa pun yang disebutkan di bawah, didistribusikan kembali kepada pemangku kepentingan yang terikat secara proporsional atom terikatnya, setiap  ValidatorPayoutPeriod  (DEFAULT 1 jam).Dari biaya transaksi yang dipungut,  ReserveTax  (DEFAULT 2%) akan dikenakan pergi menuju kumpulan cadangan untuk meningkatkan kumpulan cadangan dan meningkatkan keamanan dan nilai jaringan Cosmos. Ini dana juga dapat disalurkan sesuai dengan keputusan dibuat oleh sistem pemerintahan. Pemegang atom yang mendelegasikan hak suaranya kepada validator lainnya membayar komisi kepada validator yang didelegasikan. Komisi bisa ditetapkan oleh setiap validator. Keamanan Hub Cosmos adalah fungsi keamanan mendasari validators dan pilihan delegasi oleh delegasi. Guna mendorong penemuan dan pelaporan awal temuan kerentanan, Hub Cosmos mendorong peretas untuk mempublikasikan eksploitasi yang berhasil melalui transaksi  ReportHackTx  yang menyatakan, “Ini validator diretas. Silakan kirim hadiah ke alamat ini”. Setelah eksploitasi seperti itu, validator dan delegator akan menjadi tidak aktif,  HackPunishmentRatio  (default 5%) dari atom setiap orang akan mendapatkan dipotong, dan  HackRewardRatio  (defaultnya 5%) dari atom setiap orang akan mendapat imbalan ke alamat bounty peretas. validator harus memulihkan atom yang tersisa dengan menggunakan kunci cadangannya. Untuk mencegah fitur ini disalahgunakan untuk mentransfer atom yang tidak terikat, bagian dari atom yang terikat vs tidak terikat validators dan delegasi sebelum dan sesudah  ReportHackTx  akan tetap sama, dan hadiah hacker akan mencakup beberapa atom yang tidak terikat, jika ada. Hub Cosmos dioperasikan oleh organisasi terdistribusi yang memerlukan mekanisme tata kelola yang terdefinisi dengan baik mengoordinasikan berbagai perubahan pada blockchain, seperti variabel

parameter sistem, serta peningkatan perangkat lunak dan amandemen konstitusi. Semua validator bertanggung jawab untuk memberikan suara pada semua proposal. Gagal memberikan suara pada proposal secara tepat waktu akan menghasilkan validator dinonaktifkan secara otomatis untuk jangka waktu tertentu yang disebut  Periode Penalti Ketidakhadiran  (DEFAULT 1 minggu). Delegator secara otomatis mewarisi suara yang didelegasikan validator. Pemungutan suara ini dapat diganti secara manual. Atom yang tidak terikat tidak mendapat suara. Setiap proposal memerlukan deposit sebesar  MinimumProposalDeposit  tokens, yang mungkin merupakan kombinasi dari satu atau lebih tokens termasuk atom. Untuk setiap proposal, pemilih dapat memilih untuk menerima depositnya. Jika lebih dari separuh pemilih memilih untuk mengambil deposit (misalnya karena proposalnya adalah spam), deposit masuk ke kumpulan cadangan, kecuali atom apa pun yang dibakar. Untuk setiap usulan, pemilih dapat memilih dengan opsi berikut: Ya YaDengan Force Tidak Tidak Dengan Force Menjauhkan diri Mayoritas suara Ya atau YeaWithForce (atau Tidak atau suara NayWithForce) diperlukan agar proposal dapat diputuskan sebagai disahkan (atau diputuskan gagal), tetapi 1/3+ dapat memveto mayoritas keputusan dengan pemungutan suara “dengan paksa”. Ketika mayoritas ketat diveto, semua orang akan dihukum dengan kehilangan  VetoPenaltyFeeBlocks  (DEFAULT blok senilai 1 hari) senilai biaya (kecuali pajak yang tidak akan terpengaruh), dan partai yang memveto mayoritas

keputusan tersebut juga akan dihukum dengan kehilangan  VetoPenaltyAtoms  (DEFAULT 0,1%) atomnya. Parameter apa pun yang didefinisikan di sini dapat diubah dengan meneruskan  ParameterChangeProposal . Atom dapat diinisasi dan dana cadangan dibelanjakan dengan lolosnya  BountyProposal . Semua proposal lainnya, seperti proposal untuk meningkatkan protokol, akan dikoordinasikan melalui  TextProposal  umum. Lihat Rencananya. Ada banyak inovasi dalam konsensus blockchain dan skalabilitas dalam beberapa tahun terakhir. Bagian ini memberikan penjelasan singkat survei terhadap sejumlah hal penting tertentu. Konsensus di hadapan partisipan yang jahat adalah sebuah masalah dimulai pada awal tahun 1980an, ketika Leslie Lamport menciptakan istilah tersebut frase “Kesalahan Bizantium” untuk merujuk pada perilaku proses yang sewenang-wenang itu menyimpang dari perilaku yang diharapkan, berbeda dengan “kesalahan tabrakan”, dimana suatu proses terhenti begitu saja. Solusi awal ditemukan untuk jaringan sinkron yang memiliki batas ataslatensi pesan, meskipun penggunaan praktisnya sangat terbatas lingkungan yang terkendali seperti pengontrol pesawat dan pusat data disinkronkan melalui jam atom. Itu tidak sampai akhir tahun 90an bahwa Toleransi Kesalahan Bizantium Praktis (PBFT) [11] adalah diperkenalkan sebagai konsensus yang sinkron sebagian dan efisien algoritma mampu mentolerir hingga ⅓ proses yang berperilaku sewenang-wenang. PBFT menjadi algoritma standar, menghasilkan banyak algoritma variasi, termasuk yang terbaru yang dibuat oleh IBM sebagai bagiannya kontribusi mereka terhadap Hyperledger. Manfaat utama dari konsensus Tendermint atas PBFT adalah Tendermint memiliki struktur dasar yang lebih baik dan disederhanakan, beberapa di antaranya merupakan hasil dari penerapan paradigma blockchain. Blok Tendermint harus dilakukan secara berurutan, sehingga meniadakan kompleksitas dan overhead komunikasi yang terkait dengan PBFT perubahan tampilan. Di Cosmos dan banyak mata uang kripto, tidak ada perlu mengizinkan blok N+i di mana i >= 1 untuk dikomit, ketika blok N sendiri belum berkomitmen. Jika bandwidth adalah alasan mengapa blok N belum berkomitmen di zona Cosmos, maka penggunaannya tidak ada gunanya pembagian bandwidth suara untuk blok N+i. Jika partisi jaringan atau node ofzine adalah alasan mengapa blok N belum dikomit N+saya tidak akan berkomitmen. Selain itu, pengelompokan transaksi ke dalam blok memungkinkan Merkle-hashing reguler dari status aplikasi, bukan intisari berkala seperti skema pos pemeriksaan PBFT. Hal ini memungkinkan untuk komitmen transaksi yang lebih cepat dan dapat dibuktikan untuk klien ringan dan lebih cepat komunikasi antar-blockchain. Tendermint Core juga menyertakan banyak pengoptimalan dan fitur yang melampaui apa yang ditentukan dalam PBFT. Misalnya, blok yang diusulkan oleh validators dipecah menjadi beberapa bagian, Merkle-ized, dan bergosip sedemikian rupa sehingga meningkatkan penyiaran kinerja (lihat LibSwift [19] untuk inspirasi). Juga, Tendermint Core tidak membuat asumsi apa pun tentang point-to-point

konektivitas, dan berfungsi selama jaringan P2P ada terhubung dengan lemah. Meskipun bukan yang pertama menerapkan proof-of-stake (PoS), BitShares1.0 [12] berkontribusi besar terhadap penelitian dan adopsi PoS blockchains, khususnya yang dikenal sebagai PoS “terdelegasi”. Di BitShares, pemegang saham memilih "saksi", yang bertanggung jawab untuk memesan dan melakukan transaksi, dan "mendelegasikan", bertanggung jawab untuk mengoordinasikan pembaruan perangkat lunak dan perubahan parameter. BitShares2.0 bertujuan untuk mencapai kinerja tinggi (100k tx/s, 1s latensi) dalam kondisi ideal, dengan setiap blok ditandatangani oleh satu blok penandatanganan, dan kualitas transaksi memakan waktu lebih lama dibandingkan interval blok. Spesifikasi kanonik masih dalam pengembangan. Pemangku kepentingan dapat memberhentikan atau mengganti saksi yang berperilaku buruk pada a setiap hari, namun tidak ada jaminan signifikan dari saksi atau delegasi seperti Tendermint PoS yang dipotong kasus serangan pembelanjaan ganda yang berhasil. Membangun pendekatan yang dipelopori oleh Ripple, Stellar [13] menolak a model Perjanjian Federasi Bizantium dimana prosesnya berpartisipasi dalam konsensus bukan merupakan suatu hal yang yxed dan global himpunan yang diketahui. Sebaliknya, setiap node proses mengkurasi satu atau lebih “irisan kuorum”, yang masing-masing merupakan serangkaian proses tepercaya. SEBUAH “kuorum” di Stellar didefinisikan sebagai sekumpulan node yang berisi di setidaknya satu irisan kuorum untuk setiap node dalam himpunan, sehingga kesepakatan dapat tercapai. Keamanan mekanisme Stellar bergantung pada asumsi bahwa perpotongan dua kuorum mana pun tidak kosong, sedangkan ketersediaan sebuah node memerlukan setidaknya satu dari kuorumnya seluruhnya terdiri dari node yang benar, sehingga menciptakan trade-off di antaranya menggunakan irisan kuorum besar atau kecil yang mungkin sulit untuk diseimbangkan tanpa memaksakan asumsi signifikan tentang kepercayaan. Akhirnya,node entah bagaimana harus memilih potongan kuorum yang memadai agar dapat melakukannya memiliki toleransi kesalahan yang memadai (atau “node utuh” apa pun, di antaranya sebagian besar hasil makalah ini bergantung pada), dan satu-satunya strategi yang disediakan untuk memastikan konfigurasi semacam itu bersifat hierarkis dan mirip dengan Border Gateway Protocol (BGP), yang digunakan oleh ISP papan atas di internet untuk membuat tabel perutean global, dan oleh yang digunakan oleh browser untuk mengelola sertifikat TLS; keduanya terkenal kejam karena ketidakamanan mereka. Kritik dalam makalah Stellar terhadap sistem bukti kepemilikan berbasis Tendermint diatasi dengan strategi token yang dijelaskan di sini, di mana tipe baru token yang disebut atom dikeluarkan mewakili klaim atas bagian imbalan dan imbalan di masa depan. Itu Keuntungan dari proof-of-stake berbasis Tendermint adalah relatifnya kesederhanaan, namun tetap memberikan keamanan yang memadai dan dapat dibuktikan jaminan. BitcoinNG adalah usulan perbaikan untuk Bitcoin yang memungkinkan untuk bentuk skalabilitas vertikal, seperti meningkatkan ukuran blok, tanpa konsekuensi ekonomi negatif yang biasanya terkait dengan perubahan seperti itu, seperti dampak besar yang tidak proporsional pada penambang kecil. Peningkatan ini dicapai dengan pemisahan pemilihan pemimpin dari siaran transaksi: pemimpin adalah yang pertama dipilih oleh proof-of-work di “blok mikro”, dan kemudian mampu menyiarkan transaksi yang akan dilakukan hingga blok mikro baru ditemukan. Hal ini mengurangi kebutuhan bandwidth yang diperlukan memenangkan perlombaan PoW, memungkinkan penambang kecil bersaing secara lebih adil, dan memungkinkan transaksi dilakukan secara lebih teratur oleh penambang terakhir yang menemukan blok mikro. Casper [16] adalah algoritma konsensus proof-of-stake yang diusulkan untuk Ethereum. Modus operasi utamanya adalah “konsensus demi taruhan”. Oleh membiarkan validators bertaruh secara berulang pada blok mana yang mereka yakini akan berhasil

berkomitmen pada blockchain berdasarkan taruhan lainnya yang telah mereka lihat sejauh ini, pada akhirnya keutuhan dapat dicapai. link. Ini adalah area penelitian aktif yang dilakukan oleh tim Casper. Itu Tantangannya adalah membangun mekanisme taruhan yang bisa dilakukan terbukti menjadi strategi yang stabil secara evolusi. Manfaat utama dari Casper dibandingkan dengan Tendermint mungkin menawarkan “ketersediaan terlalu konsisten” – konsensus tidak memerlukan >⅔ kuorum hak suara – mungkin mengorbankan kecepatan komitmen atau kompleksitas implementasi. Protokol Interledger [14] tidak sepenuhnya merupakan solusi skalabilitas. Itu menyediakan interoperasi ad hoc antara buku besar yang berbeda sistem melalui jaringan hubungan bilateral yang digabungkan secara longgar. Seperti Lightning Network, tujuan ILP adalah untuk memfasilitasi pembayaran, namun secara khusus berfokus pada pembayaran yang berbeda-beda jenis buku besar, dan memperluas mekanisme transaksi atom ke tidak hanya mencakup hash-gembok, tetapi juga kuorum notaris (disebut Protokol Transportasi Atom). Mekanisme terakhir untuk menerapkan atomisitas dalam transaksi antar buku besar serupa dengan Mekanisme SPV klien ringan Tendermint, jadi ilustrasinya perbedaan antara ILP dan Cosmos/IBC dibenarkan, dan disediakan di bawah ini. 1. Notaris penghubung di ILP tidak mendukung keanggotaan perubahan, dan tidak memungkinkan adanya pembobotan yang signifikan di antara keduanya notaris. Di sisi lain, IBC dirancang khusus untuk blockchains, dimana validators dapat memiliki bobot yang berbeda, dan di mana keanggotaan dapat berubah seiring berjalannya waktu blockchain. 2. Seperti di Lightning Network, penerima pembayaran di ILP harus online untuk mengirim konfirmasi kembali ke pengirim. Di sebuahtoken transfer melalui IBC, set validator dari penerima blockchain bertanggung jawab untuk memberikan konfirmasi, bukan pengguna penerima. 3. Perbedaan yang paling mencolok adalah konektor ILP tidak bertanggung jawab atau menjaga otoritas mengenai pembayaran, sedangkan di Cosmos, validators dari sebuah hub adalah wewenang dari keadaan IBC token transfer serta kewenangannya jumlah tokens yang dimiliki oleh masing-masing zona (tetapi bukan jumlah tokens dipegang oleh setiap akun dalam suatu zona). Ini adalah inovasi mendasar yang memungkinkan asimetris aman perpindahan tokens dari zona ke zona; analog dengan ILP konektor di Cosmos bersifat persisten dan aman secara maksimal blockchain buku besar, Hub Cosmos. 4. Pembayaran antar buku besar di ILP perlu didukung oleh tukar buku pesanan, karena tidak ada transfer asimetris koin dari satu buku besar ke buku besar lainnya, hanya transfer nilai atau setara pasar. Sidechains [15] adalah mekanisme yang diusulkan untuk menskalakan Bitcoin jaringan melalui blockchain alternatif yang “dipatok dua arah”. Bitcoin blockchain. (Pegging dua arah setara dengan menjembatani. Dalam Cosmos kami mengatakan "menjembatani" untuk membedakan dari penetapan pasar). Sidechain memungkinkan bitcoin berpindah secara efektif dari Bitcoin blockchain ke rantai samping dan belakang, dan biarkan eksperimen dalam fitur-fitur baru di sidechain. Seperti di Cosmos Hub, sidechain, dan Bitcoin berfungsi sebagai klien ringan satu sama lain, menggunakan bukti SPV untuk menentukan kapan koin seharusnya dikeluarkan ditransfer ke sidechain dan kembali. Tentu saja, sejak Bitcoin menggunakan proof-of-work, rantai samping yang berpusat di sekitar Bitcoin menderita dari sekian banyak permasalahan dan resiko proof-of-work sebagai a mekanisme konsensus. Selain itu, ini adalah Bitcoin-maksimalis solusi yang tidak mendukung berbagai token dan

topologi jaringan antar zona seperti yang dilakukan Cosmos. Konon, intinya Mekanisme pasak dua arah pada prinsipnya sama dengan itu dipekerjakan oleh jaringan Cosmos. Ethereum saat ini sedang meneliti sejumlah strategi berbeda untuk membagi status Ethereum blockchain ke alamat kebutuhan skalabilitas. Upaya tersebut mempunyai tujuan untuk mempertahankan lapisan abstraksi yang ditawarkan oleh Mesin Virtual Ethereum saat ini melintasi ruang negara bersama. Berbagai upaya penelitian adalah sedang berlangsung saat ini. [18][22] Cosmos dan Ethereum 2.0 Mauve [22] memiliki tujuan desain yang berbeda. Cosmos khususnya tentang tokens. Mauve adalah tentang penskalaan perhitungan umum. Cosmos tidak terikat pada EVM, jadi VM yang berbeda pun bisa saling beroperasi. Cosmos memungkinkan pembuat zona menentukan siapa yang memvalidasi zona. Siapa pun dapat memulai zona baru di Cosmos (kecuali tata kelola memutuskan sebaliknya). Hub mengisolasi kegagalan zona sehingga ada invarian token global dilestarikan. Lightning Network adalah jaringan transfer token yang diusulkan beroperasi pada lapisan di atas Bitcoin blockchain (dan publik lainnya blockchains), memungkinkan peningkatan berkali-kali lipat dalam throughput transaksi dengan memindahkan sebagian besar transaksi di luar buku besar konsensus ke dalam apa yang disebut “saluran pembayaran”.Hal ini dimungkinkan oleh skrip mata uang kripto on-chain, yang memungkinkan para pihak untuk mengadakan kontrak negara bilateral di mana negara dapat diperbarui dengan berbagi tanda tangan digital, dan kontrak dapat ditutup dengan menerbitkan bukti secara tahunan ke blockchain, a mekanisme yang pertama kali dipopulerkan oleh pertukaran atom lintas rantai. Oleh membuka saluran pembayaran dengan banyak pihak, peserta Lightning Network dapat menjadi titik fokus untuk routing pembayaran pihak lain, yang mengarah ke saluran pembayaran yang terhubung sepenuhnya jaringan, dengan biaya modal yang terikat pada saluran pembayaran. Sedangkan Lightning Network juga dapat dengan mudah diperluas beberapa blockchain independen untuk memungkinkan transfer nilai melalui pasar pertukaran, tidak dapat digunakan secara asimetris transfer tokens dari satu blockchain ke yang lain. Manfaat utama dari jaringan Cosmos yang dijelaskan di sini adalah untuk mengaktifkan langsung tersebut token transfer. Meskipun demikian, kami mengharapkan saluran pembayaran dan Lightning Network menjadi diadopsi secara luas bersama dengan kami token mekanisme transfer, untuk alasan penghematan biaya dan privasi. Segregated Witness adalah tautan proposal perbaikan Bitcoin itu bertujuan untuk meningkatkan throughput transaksi per blok 2X atau 3X, sekaligus mempercepat sinkronisasi blok untuk node baru. Kecemerlangan solusi ini terletak pada cara kerjanya di dalam keterbatasan protokol Bitcoin saat ini dan memungkinkan adanya soft-fork upgrade (yaitu klien dengan versi perangkat lunak yang lebih lama akan terus berfungsi setelah peningkatan). Tendermint, menjadi yang baru protokol, tidak memiliki batasan desain, sehingga memiliki skala yang berbeda prioritas. Terutama, Tendermint menggunakan algoritma round-robin BFT berdasarkan tanda tangan kriptografi, bukan penambangan, yang mana secara sepele memungkinkan penskalaan horizontal melalui beberapa paralel blockchains, meskipun penerapan blok yang teratur dan lebih sering memungkinkan penskalaan vertikal juga.

الإجماع والتفاصيل الفنية

ينبغي لبروتوكول الإجماع المصمم جيدًا أن يوفر بعضًا من ذلك الضمانات في حالة تجاوز قدرة التسامح ويفشل الإجماع. وهذا ضروري بشكل خاص في المجال الاقتصادي الأنظمة، حيث يمكن أن يكون للسلوك البيزنطي قدر كبير من المال مكافأة. وأهم هذه الضمانات هو شكل من أشكال المساءلة، حيث تتم العمليات التي تسببت في الإجماع الفشل (أي جعل عملاء البروتوكول يقبلون قيمًا مختلفة - أ fork) يمكن تحديد هويته ومعاقبته وفقًا لقواعد البروتوكول، أو ربما النظام القانوني. عندما يكون النظام القانوني يمكن أن يكون استدعاء validators غير موثوق به أو باهظ التكلفة اضطروا إلى تقديم ودائع ضمان من أجل المشاركة، وهؤلاء يمكن إلغاء الودائع أو تخفيضها عند حدوث سلوك ضار تم اكتشاف [10]. لاحظ أن هذا يختلف عن Bitcoin، حيث يكون التفرع حدثًا منتظمًا بسبب عدم تزامن الشبكة والطبيعة الاحتمالية للنهاية الاصطدامات الجزئية hash. نظرًا لأنه في كثير من الحالات يكون هناك شوكة ضارة لا يمكن تمييزه عن الشوكة بسبب عدم التزامن، Bitcoin لا يمكن تنفيذ مسؤولية الشوكة بشكل موثوق، بخلاف الضمنية تكلفة الفرصة البديلة التي يدفعها عمال المناجم لتعدين كتلة معزولة. نحن نطلق على مرحلتي التصويت PreVote وPreCommit. يمكن التصويت ل كتلة معينة أو لا شيء. نحن نطلق على مجموعة من >⅔ الأصوات المسبقة لكتلة واحدة في نفس الجولة رقصة البولكا، ومجموعة من >⅔ الالتزام المسبق لكتلة واحدة في نفس جولة الالتزام. إذا> ⅔ الالتزام المسبق لـ Nil في نفس الجولة، ينتقلون إلى الجولة التالية جولة. لاحظ أن الحتمية الصارمة في البروتوكول تنطوي على ضعف يجب اكتشاف افتراض التزامن كقادة خاطئين

تم تخطيه. ومن ثم، ينتظر validators بعض الوقت، TimeoutPropose، قبل أن يصوتوا على Nil، وقيمة TimeoutPropose يزيد مع كل جولة. التقدم من خلال بقية الجولة غير متزامنة تمامًا، في هذا التقدم فقط يتم إجراؤه بمجرد سماع validator من >⅔ الشبكة. في الممارسة العملية، سوف يتطلب الأمر وجود خصم قوي للغاية لإحباطه إلى أجل غير مسمى افتراض التزامن الضعيف (مما يتسبب في فشل الإجماع من أي وقت مضى ارتكاب كتلة)، والقيام بذلك يمكن أن يتم أكثر من ذلك من الصعب استخدام القيم العشوائية لـ TimeoutPropose في كل منها validator. هناك مجموعة إضافية من القيود، أو قواعد القفل، تضمن أن ستلتزم الشبكة في النهاية بكتلة واحدة فقط عند كل ارتفاع. أي محاولة خبيثة للتسبب في ارتكاب أكثر من كتلة واحدة على ارتفاع معين يمكن تحديدها. أولاً، الالتزام المسبق للكتلة يجب أن يأتي مع مبرر، في شكل رقصة البولكا لتلك الكتلة. إذا كان validator قد قام بالفعل بتنفيذ كتلة في الجولة R_1، فإننا ويقول أنهم مقفلون على تلك الكتلة، ويستخدم رقصة البولكا لتبرير يجب أن يأتي الالتزام المسبق الجديد في الجولة R_2 في جولة R_polka حيث R_1 < R_polka <= R_2. ثانيًا، يجب أن يقترح validators و/أو قم بالتصويت المسبق على الكتلة التي تم قفلها عليها. معا، هؤلاء تضمن الشروط أن validator لا يتم الالتزام المسبق بدونه أدلة كافية لتبرير ذلك، وأن validators التي لديها بالفعل لا يمكن لـ PreCommit المساهمة في الأدلة المقدمة إلى PreCommit شيء آخر. وهذا يضمن سلامة وحيوية الجسم خوارزمية الإجماع. يتم وصف التفاصيل الكاملة للبروتوكول هنا. يتم التخلص من الحاجة إلى مزامنة جميع رؤوس الكتل في TendermintPoS حيث أن وجود سلسلة بديلة (شوكة) يعني ≥⅓ من يمكن خفض الحصة المستعبدة. بالطبع، لأن القطع يتطلب أن يشارك شخص ما دليلاً على الشوكة، يجب على العملاء الخفيفين تخزينها أي كتلة-hash ترتكب ما تراه. بالإضافة إلى العملاء الخفيفينيمكن أن تظل متزامنة بشكل دوري مع التغييرات التي يتم إجراؤها على مجموعة validator، في لتجنب الهجمات بعيدة المدى (ولكن الحلول الأخرى هي ممكن). بروح مشابهة لـ Ethereum، يتيح Tendermint للتطبيقات القيام بذلك قم بتضمين جذر Merkle العالمي hash في كل كتلة، مما يسمح بذلك بسهولة استعلامات حالة يمكن التحقق منها لأشياء مثل أرصدة الحسابات، والقيمة المخزنة في العقد، أو وجود معاملة غير منفقة الإخراج، اعتمادا على طبيعة التطبيق. بافتراض وجود مجموعة مرنة بما فيه الكفاية من شبكات البث ومجموعة validator ثابتة، أي شوكة في blockchain يمكن أن تكون تم اكتشافها وخفض رواسب validators المخالفة. هذا الابتكار، الذي اقترحه فيتاليك بوتيرين لأول مرة في أوائل عام 2014، يحل المشكلة مشكلة عدم وجود شيء على المحك للآخرين proof-of-stake العملات المشفرة (انظر الأعمال ذات الصلة). ومع ذلك، منذ validator مجموعات يجب أن تكون قادرة على تغيير الأصل، على مدى فترة طويلة من الزمن قد يصبح جميع validators غير مقيدين، وبالتالي سيكونون أحرارًا في ذلك إنشاء سلسلة جديدة من كتلة التكوين، دون تحمل أي تكلفة لم يعد لديهم ودائع مقفلة. وجاء هذا الهجوم ليكون المعروف باسم الهجوم بعيد المدى (LRA)، على عكس الهجوم القصير هجوم النطاق، حيث يتسبب validators المرتبطين حاليًا في حدوث أ شوكة ومن ثم يعاقب عليها (بافتراض وجود شوكة مسؤولة BFT خوارزمية مثل إجماع Tendermint). الهجمات بعيدة المدى هي غالبًا ما يُعتقد أنها بمثابة ضربة حاسمة لـ proof-of-stake. ولحسن الحظ، يمكن التخفيف من حدة جيش الرب للمقاومة على النحو التالي. أولا بالنسبة ل validator لإلغاء الارتباط (وبالتالي استرداد وديعة الضمان الخاصة بهم ولم يعد يكسب رسوم المشاركة في الإجماع). يجب أن تكون الوديعة غير قابلة للتحويل لفترة من الوقت المعروفة باسم "فترة التفكيك"، والتي قد تكون في حدود أسابيع أو أشهر. ثانيًا، لكي يكون العميل الخفيف آمنًا، الأول عند اتصاله بالشبكة، يجب عليه التحقق من الحظر الأخير-hash ضد مصدر موثوق به، أو يفضل عدة مصادر. هذا

يُشار إلى الحالة أحيانًا باسم "الذاتية الضعيفة". وأخيرا، لكي يظل آمنًا، يجب أن تتم مزامنته مع أحدث validator المعين في على الأقل بشكل متكرر مثل طول فترة فك الارتباط. هذا يضمن أن العميل الخفيف يعرف التغييرات التي تم إجراؤها على validator تم تعيينه قبل validator وقد تم إلغاء رأس ماله وبالتالي لم يعد كذلك على المحك، مما يسمح لها بخداع العميل بتنفيذها هجوم بعيد المدى عن طريق إنشاء كتل جديدة تبدأ من مرة أخرى الارتفاع حيث تم ربطه (بافتراض أنه يتحكم بشكل كافٍ العديد من المفاتيح الخاصة المبكرة). لاحظ أن التغلب على جيش الرب للمقاومة بهذه الطريقة يتطلب إصلاحًا شاملاً نموذج الأمان الأصلي لـ proof-of-work. في إثبات العمل، هو كذلك من المفترض أن العميل الخفيف يمكنه المزامنة مع الارتفاع الحالي من كتلة التكوين الموثوق بها في أي وقت ببساطة عن طريق معالجة إثبات العمل في كل رأس كتلة. ولكن للتغلب على جيش الرب للمقاومة، علينا تتطلب أن يأتي العميل الخفيف عبر الإنترنت مع بعض الانتظام تتبع التغييرات في مجموعة validator، وذلك في المرة الأولى التي يتم فيها ذلك متصلين بالإنترنت ويجب عليهم أن يكونوا حريصين بشكل خاص على المصادقة ما يسمعونه من الشبكة ضد مصادر موثوقة. من بالطبع، هذا المتطلب الأخير مشابه لمتطلب Bitcoin، حيث ويجب أيضًا الحصول على البروتوكول والبرمجيات من جهة موثوقة المصدر. الطريقة المذكورة أعلاه لمنع جيش الرب للمقاومة مناسبة تمامًا لـ validators والعقد الكاملة لـ blockchain التي تعمل بنظام Tendermint لأن هذه من المفترض أن تظل العقد متصلة بالشبكة. ال الطريقة مناسبة أيضًا للعملاء الخفيفين الذين يمكن توقعهم المزامنة مع الشبكة بشكل متكرر. ومع ذلك، بالنسبة للعملاء الخفيفين ليس من المتوقع أن يكون لديك إمكانية الوصول المتكرر إلى الإنترنت أو blockchain الشبكة، ولكن يمكن استخدام حل آخر للتغلب عليها جيش الرب للمقاومة. يمكن لحاملي غير validator token نشر tokens باسمهم الضمانات ذات فترة فك الارتباط طويلة جدًا (على سبيل المثال، أطول بكثير من فترة إلغاء الارتباط لـ validators) وخدمة العملاء الخفيفين مع طريقة ثانوية لإثبات صحة التيار و الكتلة الماضية-hashes. في حين أن هذه tokens لا يتم احتسابها ضمن أمان إجماع blockchain، ومع ذلك يمكنهم ذلكتقديم ضمانات قوية للعملاء الخفيفين. إذا كانت الكتلة التاريخية-hash تم دعم الاستعلام في Ethereum، ويمكن لأي شخص ربطه tokens في smart contract المصممة خصيصًا وتقديمها خدمات التصديق مقابل الأجر، مما يؤدي بشكل فعال إلى إنشاء سوق لأمن LRA من عملاء Lightclient. نظرًا لتعريف التزام الكتلة، فإن أي ≥⅓ تحالف من يمكن لقوة التصويت أن توقف blockchain بالذهاب إلى الخارج أم لا بث أصواتهم يمكن لمثل هذا التحالف أيضًا فرض الرقابة معاملات معينة عن طريق رفض الكتل التي تتضمن هذه المعاملات المعاملات، على الرغم من أن هذا من شأنه أن يؤدي إلى نسبة كبيرة من مقترحات الكتلة التي سيتم رفضها، الأمر الذي من شأنه أن يبطئ المعدل من عمليات تنفيذ الحظر لـ blockchain، مما يقلل من فائدته وقيمته. قد يقوم التحالف الخبيث أيضًا ببث الأصوات بشكل متقطع كما أن طحن كتلة blockchain تلتزم بالتوقف القريب أو الانخراط أي مزيج من هذه الهجمات. وأخيرا، يمكن أن يسبب blockchain إلى الشوكة، بالتوقيع المزدوج أو انتهاك القفل القواعد. وإذا شارك أيضًا خصم نشط عالميًا، فيمكنه التقسيم الشبكة بطريقة قد تبدو خاطئة كانت مجموعة فرعية من validators مسؤولة عن التباطؤ. هذا ليس كذلك مجرد قيود على Tendermint، بل هي قيود على الجميع بروتوكولات الإجماع التي من المحتمل أن يتم التحكم في شبكتها بواسطة الخصم النشط. بالنسبة لهذه الأنواع من الهجمات، ينبغي لمجموعة فرعية من validators التنسيق من خلال وسائل خارجية للتوقيع على مقترح إعادة التنظيم يختار شوكة (وأي دليل على ذلك) والمجموعة الفرعية الأولية من validators مع توقيعاتهم. يتخلى المصادقون الذين يوقعون على مقترح إعادة التنظيم هذا عن ضماناتهم على جميع الشوكات الأخرى. يجب على العملاء التحقق من التوقيعات على مقترح إعادة التنظيم، والتحقق من أي دليل، وإصدار حكم أو مطالبة المستخدم النهائي باتخاذ قرار. ل على سبيل المثال، قد يطلب تطبيق محفظة الهاتف من المستخدم توفير الأمان

تحذير، في حين أن الثلاجة قد تقبل أي اقتراح لإعادة التنظيم موقعة من +½ من أصل validators بقوة التصويت. لا يمكن أن تأتي خوارزمية بيزنطية غير متزامنة متسامحة مع الأخطاء إلى الإجماع عندما يكون ≥⅓ من قوة التصويت غير شريفة، ومع ذلك فهو شوكة يفترض أن ≥⅓ من قوة التصويت كانت غير شريفة بالفعل التوقيع المزدوج أو تغيير القفل دون مبرر. لذلك، التوقيع إن اقتراح إعادة التنظيم يمثل مشكلة تنسيق لا يمكن حلها يتم حلها بواسطة أي بروتوكول غير متزامن (أي تلقائيًا، و دون وضع افتراضات حول موثوقية الشبكة الأساسية). في الوقت الحالي، نترك مشكلة تنسيق إعادة التنظيم للتنسيق البشري من خلال الإجماع الاجتماعي على وسائل الإعلام عبر الإنترنت. يجب على المصادقين الحرص على التأكد من ذلك لا توجد أقسام شبكة متبقية قبل التوقيع على اقتراح إعادة التنظيم، لتجنب المواقف التي يتم فيها التوقيع على اقتراحين متعارضين لإعادة التنظيم. على افتراض أن وسيلة التنسيق الخارجي والبروتوكول قوية، ويترتب على ذلك أن الشوكات أقل إثارة للقلق من الرقابة الهجمات. بالإضافة إلى الشوكة والرقابة التي تتطلب ≥⅓ البيزنطية قوة التصويت، قد يلتزم ائتلاف من >⅔ قوة التصويت حالة تعسفية وغير صالحة. وهذه هي سمة أي (BFT) نظام الإجماع. على عكس التوقيع المزدوج الذي يخلق الشوكات بأدلة يمكن التحقق منها بسهولة، والكشف عن ارتكاب جريمة ما تتطلب الحالة غير الصالحة أن يقوم أقران لم يتم التحقق من صحتهم بالتحقق من الكتل بأكملها، مما يعني أنهم يحتفظون بنسخة محلية من الدولة وينفذونها كل معاملة، وحساب جذر الدولة بشكل مستقل ل أنفسهم. وبمجرد الكشف عنها، فإن الطريقة الوحيدة للتعامل مع مثل هذا الفشل يتم عن طريق الإجماع الاجتماعي. على سبيل المثال، في المواقف التي يكون فيها Bitcoin قد فشل، سواء كان التفرع بسبب أخطاء برمجية (كما في مارس 2013)، أو ارتكاب حالة باطلة بسبب السلوك البيزنطي عمال المناجم (كما في يوليو 2015)، مجتمع متصل جيدًا بـ الشركات والمطورين وعمال المناجم وغيرها من المنظمات أنشأ إجماعًا اجتماعيًا حول ماهية الإجراءات اليدويةالمطلوبة من قبل المشاركين لشفاء الشبكة. وعلاوة على ذلك، منذ من المتوقع أن يكون validators من النعناع blockchain يمكن تحديدها، بل قد يكون التزام دولة غير صالحة يعاقب عليها القانون أو بعض الاجتهادات القضائية الخارجية، إذا رغبت في ذلك. ABCI يتكون من 3 أنواع رسائل أساسية يتم تسليمها منها جوهر التطبيق. التطبيق يجيب ب رسائل الرد المقابلة. تعتبر رسالة  AppendTx  بمثابة العمود الفقري للتطبيق. كل يتم تسليم المعاملة في blockchain مع هذه الرسالة. ال يحتاج التطبيق إلى التحقق من صحة كل المعاملات الواردة مع رسالة AppendTx مقابل الحالة الحالية، وبروتوكول التطبيق، وبيانات اعتماد التشفير للمعاملة. تم التحقق من صحتها تحتاج المعاملة بعد ذلك إلى تحديث حالة التطبيق — بواسطة ربط قيمة في مخزن القيم الأساسية، أو عن طريق تحديث UTXO قاعدة البيانات. تشبه رسالة  CheckTx  رسالة AppendTx، ولكنها مخصصة فقط لـ التحقق من صحة المعاملات. الشيكات الأولى لذاكرة Tendermint Core صلاحية المعاملة مع CheckTx، والمرحلات صالحة فقط المعاملات لأقرانها. قد تحقق التطبيقات زيادة nonce في المعاملة وإرجاع خطأ عند CheckTx إذا كان nonce قديم. يتم استخدام رسالة  Commit  لحساب التشفير الالتزام بحالة التطبيق الحالية، ليتم وضعها في رأس الكتلة التالي. هذا له بعض الخصائص المفيدة. ستظهر الآن التناقضات في تحديث تلك الحالة blockchain شوكات تلتقط فئة كاملة من البرمجة أخطاء. وهذا أيضًا يبسط عملية تطوير آمنة وخفيفة الوزن العملاء، حيث يمكن التحقق من أدلة Merkle-hash عن طريق التحقق منها الكتلة-hash، والكتلة-hash تم توقيعها بنصاب قانوني validators (حسب قوة التصويت).

تسمح رسائل ABCI الإضافية للتطبيق بتتبعها وقم بتغيير مجموعة validator، ولكي يحصل التطبيق على معلومات الحظر، مثل الارتفاع وأصوات الالتزام. ABCI الطلبات/الردود هي رسائل Protobuf بسيطة. تحقق خارج المخطط. الحجج: البيانات ([]بايت): بايتات معاملة الطلب العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايتات النتيجة، إن وجدت السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:

إلحاق المعاملة وتشغيلها. إذا كانت الصفقة صحيحة ترجع CodeType.OK الحجج: البيانات ([]بايت): بايتات معاملة الطلب العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايتات النتيجة، إن وجدت السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:

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

العوائد: البيانات ([]بايت): جذر Merkle hash السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:

قم بإرجاع جذر Merkle hash لحالة التطبيق. الحجج: البيانات ([]بايت): بايتات طلب الاستعلام العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايت استجابة الاستعلام السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:

مسح قائمة انتظار الاستجابة. التطبيقات التي تنفذ أنواع.لا يحتاج التطبيق إلى تنفيذ هذه الرسالة - إنه كذلك يعالجها المشروع. العوائد: البيانات ([]بايت): بايت المعلومات الاستخدام:

إرجاع معلومات حول حالة التطبيق. التطبيق com.speciyc. الحجج: المفتاح (سلسلة): مفتاح للضبط

القيمة (سلسلة): القيمة المطلوب تعيينها للمفتاح العوائد: السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:

ضبط خيارات التطبيق. على سبيل المثال. المفتاح = "الوضع"، القيمة = "mempool" لـ اتصال mempool، أو المفتاح = "الوضع"، القيمة = "الإجماع" لـ اتصال توافقي. الخيارات الأخرى هي تطبيق محدد. الحجج: أدوات التحقق من الصحة ([] أداة التحقق من الصحة): التكوين الأولي-validators الاستخدام:

دعا مرة واحدة في سفر التكوين الحجج: الارتفاع (uint64) : ارتفاع الكتلة الذي يبدأ الاستخدام:

يشير إلى بداية كتلة جديدة. دعا قبل أي إلحاقTxs. الحجج: الارتفاع (uint64) : ارتفاع الكتلة الذي انتهى العوائد: أدوات التحقق ([]أداة التحقق) : تم تغيير validators بأخرى جديدة صلاحيات التصويت (0 لإزالة) الاستخدام:

إشارات نهاية الكتلة. تم الاتصال به قبل كل التزام بعد كل شيء المعاملات راجع مستودع ABCI لمزيد من التفاصيل.هناك عدة أسباب وراء رغبة المرسل في الحصول على إقرار بتسليم الحزمة من خلال سلسلة الاستقبال. على سبيل المثال، قد لا يعرف المرسل حالة الملف سلسلة الوجهة، إذا كان من المتوقع أن تكون معيبة. أو يجوز للمرسل تريد فرض مهلة على الحزمة (باستخدام MaxHeight  packet yeld)، في حين أن أي سلسلة وجهة قد تعاني من هجوم رفض الخدمة مع ارتفاع مفاجئ في عدد الرسائل الواردة الحزم. في هذه الحالات، يمكن للمرسل أن يطلب إقرار التسليم من خلال تعيين حالة الحزمة الأولية على  AckPending. ثم، هو مسؤولية سلسلة الاستلام عن التسليم عن طريق تضمين يُختصر  IBCPacket  في تطبيق Merkle hash. أولاً، تم نشر IBCBlockCommit و IBCPacketTx على "Hub" مما يثبت وجود IBCPacket على "Zone1". قل ذلك  IBCPacketTx  له القيمة التالية: من معرف السلسلة: "المنطقة 1" من بلوك الارتفاع: 100 (على سبيل المثال) الحزمة : IBC الحزمة :

الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" الرقم: 200 (قل) الحالة: قيد الانتظار النوع: "عملة" MaxHeight : 350 (قل "Hub" حاليًا على ارتفاع 300) الحمولة: <بايتات الحمولة "العملة"> بعد ذلك، يتم نشر IBCBlockCommit و IBCPacketTx على "Zone2" مما يثبت وجود IBCPacket على "Hub". قل ذلك  IBCPacketTx  له القيمة التالية: FromChainID: "المركز" من ارتفاع الكتلة: 300 الحزمة : IBC الحزمة : الرأس: IBCPacketHeader: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: قيد الانتظار النوع: "عملة" أقصى ارتفاع: 350 الحمولة: <نفس وحدات البايت لحمولة "العملة"> بعد ذلك، يجب أن تتضمن "Zone2" في تطبيقها-hash حزمة مختصرة الذي يوضح الحالة الجديدة لـ  AckSent. IBCBlockCommit و  IBCPacketTx  تم نشرها مرة أخرى على "Hub" مما يثبت وجودها من IBCPacket المختصرة في "Zone2". قل ذلك IBCPacketTx  له القيمة التالية: من معرف السلسلة: "المنطقة 2"

من بلوك الارتفاع: 400 (على سبيل المثال) الحزمة : IBC الحزمة : الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: تم الإرسال النوع: "عملة" أقصى ارتفاع: 350 PayloadHash : <البايتات hash من نفس الحمولة النافعة "للعملة"> وأخيرًا، يجب على "Hub" تحديث حالة الحزمة من  "AckPending" إلى "AckReceived". دليل على هذا الوضع الجديد ynalized يجب أن يعود إلى "المنطقة 2". لنفترض أن IBCPacketTx  يحتوي على ما يلي القيمة: FromChainID: "المركز" من ارتفاع الكتلة: 301 الحزمة : IBC الحزمة : الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: تم الاستلام النوع: "عملة" أقصى ارتفاع: 350 PayloadHash : <البايتات hash من نفس الحمولة النافعة "للعملة"> وفي الوقت نفسه، قد تفترض "المنطقة 1" بشكل متفائل التسليم الناجح حزمة "النقود المعدنية" ما لم يثبت خلاف ذلك "المحور". في المثال أعلاه، إذا لم يتلق "Hub" رسالة AckSent

الحالة من "المنطقة 2" بواسطة الكتلة 350، كانت ستحدد الحالة تلقائيًا إلى  المهلة. يمكن الحصول على هذا الدليل على المهلة تم نشرها مرة أخرى على "Zone1"، ويمكن إرجاع أي tokens. هناك نوعان من Merkle trees مدعومان في النظام البيئي Tendermint/Cosmos: الشجرة البسيطة وIAVL+ شجرة. الشجرة البسيطة هي Merkle tree لقائمة ثابتة من العناصر. إذا عدد العناصر ليس قوة اثنين، وبعض الأوراق ستكون في مستويات مختلفة. تحاول Simple Tree الحفاظ على جانبي الشجرة نفس الارتفاع، ولكن اليسار قد يكون أكبر من ذلك. هذا Merkle tree هو يستخدم لـ Merkle-ize معاملات الكتلة والمستوى الأعلى عناصر جذر حالة التطبيق.الغرض من بنية بيانات IAVL+ هو توفير الدعم المستمر تخزين أزواج القيمة الرئيسية في حالة التطبيق بحيث يكون أ يمكن حساب جذر Merkle الحتمي hash بكفاءة. ال تتم موازنة الشجرة باستخدام البديل من خوارزمية AVL، وجميع العمليات هي O(log(n)). في شجرة AVL، ارتفاعات الشجرتين الفرعيتين لأي عقدة تختلف بواحدة على الأكثر. كلما تم انتهاك هذا الشرط على التحديث، يتم إعادة توازن الشجرة عن طريق إنشاء العقد الجديدة O(log(n)) التي أشر إلى العقد غير المعدلة من الشجرة القديمة. في AVL الأصلي الخوارزمية، يمكن للعقد الداخلية أيضًا الاحتفاظ بأزواج القيمة الرئيسية. ايه في ال+ الخوارزمية (لاحظ الزائد) تقوم بتعديل خوارزمية AVL للاحتفاظ بكل شيء القيم على العقد الطرفية، مع استخدام العقد الفرعية فقط لتخزين المفاتيح. يؤدي هذا إلى تبسيط الخوارزمية مع الحفاظ على مسار Merkle hash قصيرة. تشبه شجرة AVL+ محاولات باتريشيا Ethereum. هناك المقايضات. لا يلزم أن تكون المفاتيح hashed قبل إدراجها أشجار IAVL+، مما يوفر تكرارًا مرتبًا بشكل أسرع في المفتاح المساحة التي قد تفيد بعض التطبيقات. المنطق هو أبسط ل تنفيذ، يتطلب نوعين فقط من العقد - العقد الداخلية و العقد الورقية. إن برهان ميركل أقصر في المتوسط، كونه أ                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *       *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    شجرة بسيطة تحتوي على 7 عناصر

شجرة ثنائية متوازنة من ناحية أخرى، جذر ميركل ل تعتمد شجرة IAVL+ على ترتيب التحديثات. سوف ندعم المزيد من Merkle trees، مثل Ethereum باتريشيا تري عندما يصبح المتغير الثنائي متاح. في التنفيذ الأساسي، يتم تدفق المعاملات إلى Cosmos تطبيق المحور عبر واجهة ABCI. سيقبل Cosmos Hub عددًا من المعاملات الأساسية الأنواع، بما في ذلك  SendTx ،  BondTx ،  UnbondTx ،  ReportHackTx ،  SlashTx، وBurnAtomTx، وProposalCreateTx، وProposalVoteTx، والتي لا تحتاج إلى شرح إلى حد ما وسيتم توثيقها في ملف المراجعة المستقبلية لهذه الورقة. هنا نقوم بتوثيق الأمرين الأساسيين أنواع المعاملات لـ IBC:  IBCBlockCommitTx  و  IBCPacketTx . تتكون معاملة  IBCBlockCommitTx  من: ChainID (سلسلة): معرف blockchain BlockHash ([]بايت): الكتلة-hash بايت، جذر Merkle والذي يتضمن التطبيق-hash BlockPartsHeader (PartSetHeader): رأس مجموعة أجزاء الكتلة البايتات، مطلوبة فقط للتحقق من توقيعات التصويت BlockHeight (int) : ارتفاع الالتزام BlockRound (int): جولة الالتزام الالتزام ([]تصويت) : يصوت >⅔ Tendermint Precommit على ذلك تتضمن التزامًا بالكتلة ValidatorsHash ([]بايت): جذر شجرة ميركل hash للجديد validator مجموعة

ValidatorsHashProof (SimpleProof): SimpleTree Merkleproof لإثبات ValidatorsHash مقابل BlockHash AppHash ([]بايت): جذر شجرة IAVLTree Merkle hash لـ حالة التطبيق AppHashProof (SimpleProof): أداة SimpleTree Merkle-proof لـ إثبات AppHash مقابل BlockHash تتكون الحزمة IBCPacket من: Header (IBCPacketHeader): رأس الحزمة الحمولة ([]بايت): بايتات حمولة الحزمة. اختياري PayloadHash ([]بايت): hash لبايتات الحزمة. اختياري يجب أن يكون أي من  Payload أو  PayloadHash موجودًا. hash  IBCPacket  هو جذر Merkle البسيط للعنصرين،  الرأس  و  الحمولة. يُطلق على  IBCPacket  بدون الحمولة الكاملة اسم الحزمة المختصرة. يتكون  IBCPacketHeader  من: SrcChainID (سلسلة): معرف المصدر blockchain DstChainID (سلسلة): معرف الوجهة blockchain الرقم (int) : رقم فريد لجميع الحزم الحالة (التعداد): يمكن أن تكون واحدة من AckPending أو AckSent أو AckReceived أو NoAck أو Timeout النوع (سلسلة): تعتمد الأنواع على التطبيق. Cosmos يحتفظ بنوع الحزمة "العملة المعدنية". MaxHeight (int) : إذا كانت الحالة ليست NoAckWanted أو AckReceived وبهذا الارتفاع، تصبح الحالة Timeout . اختياري تتكون معاملة IBCPacketTx من:FromChainID (سلسلة): معرف blockchain وهو توفير هذه الحزمة؛ ليس بالضرورة المصدر FromBlockHeight (int) : الارتفاع blockchain الذي يوجد فيه تم تضمين الحزمة التالية (بحجم Merkle) في الكتلة-hash من سلسلة المصدر الحزمة (IBCPacket): حزمة من البيانات، قد تكون حالتها واحدة AckPending أو AckSent أو AckReceived أو NoAck أو Timeout PacketProof (IAVLProof): IAVLTree Merkle-proof للإثبات الحزمة hash مقابل AppHash لسلسلة المصدر في ارتفاع معين تسلسل إرسال الحزمة من "Zone1" إلى "Zone2" من خلال "المحور" كما هو موضح في {الشكل X}. أولاً، IBCPacketTx  يثبت لـ "Hub" أن الحزمة مضمنة في حالة التطبيق "المنطقة 1". بعد ذلك، يثبت IBCPacketTx آخر لـ "Zone2" أن يتم تضمين الحزمة في حالة التطبيق "Hub". خلال هذا الإجراء، تكون حقول  IBCPacket  متطابقة:  SrcChainID  هو دائمًا "Zone1"، ويكون  DstChainID  دائمًا "Zone2". يجب أن يشتمل  PacketProof  على المسار الصحيح لـ Merkle-proof، مثل يلي: عندما يريد "Zone1" إرسال حزمة إلى "Zone2" من خلال "Hub"، تكون بيانات  IBCPacket  متطابقة سواء كانت الحزمة Merkleized على "Zone1" أو "Hub" أو "Zone2". الحقل الوحيد القابل للتغيير هو  الحالة  لتتبع التسليم. ونشكر أصدقائنا وزملائنا الذين ساعدونا في وضع المفهوم، مراجعة وتقديم الدعم لعملنا مع Tendermint و Cosmos. IBC///<الرقم>

قدم زكي مانيان من SkuChain الكثير من المساعدة في التنسيق والتنسيق الصياغة، خاصة ضمن القسم ABCI جيهان تريمباك من ألثيا وداستن بينجتون للمساعدة التكرارات الأولية أندرو ميلر من Honey Badger للحصول على تعليقات حول الإجماع جريج سليباك للحصول على تعليقات بشأن الإجماع والصياغة شكرًا أيضًا لبيل جليم وسيونغهوان هان على جهودهما المتنوعة المساهمات. اسمك ومنظمتك هنا لمساهمتك 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 زيرو كاش: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 الشاهد المنفصل: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 شبكة البرق: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 النعناع: https://github.com/tendermint/tendermint/wiki 9 استحالة FLP: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 المشرح: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 فBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 بت: https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 دفتر الأستاذ: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 سلسلة جانبية: https://blockstream.com/sidechains.pdf 16 كاسبر: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum المشاركة: https://github.com/ethereum/EIPs/issues/53 19 ليب سويفت: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysOfLibswift.pdf 20 دي إل إس: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 أمان العميل الرقيق: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 ورق بنفسجي: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

Ó ه

Konsensus dan Detail Teknis

Protokol konsensus yang dirancang dengan baik dapat memberikan beberapa hal jaminan apabila kapasitas toleransi terlampaui dan konsensus gagal. Hal ini terutama diperlukan dalam bidang ekonomi sistem, di mana perilaku Bizantium dapat mempunyai dampak finansial yang besar hadiah. Jaminan yang paling penting tersebut adalah bentuk akuntabilitas, dimana proses-proses itu menimbulkan konsensus gagal (yaitu menyebabkan klien protokol menerima nilai yang berbeda - a garpu) dapat diidentifikasi dan dihukum sesuai dengan aturan protokol, atau, mungkin, sistem hukum. Ketika sistem hukumnya tidak dapat diandalkan atau terlalu mahal untuk digunakan, validator bisa jadi dipaksa untuk memberikan uang jaminan untuk berpartisipasi, dan itu simpanan dapat dicabut, atau dipotong, apabila terjadi perilaku jahat terdeteksi [10]. Perhatikan bahwa ini tidak seperti Bitcoin, di mana forking adalah kejadian biasa karena asinkronnya jaringan dan sifat probabilistik dari hasil pencarian tabrakan sebagian hash. Karena dalam banyak kasus ada garpu berbahaya tidak dapat dibedakan dari garpu karena asinkron, Bitcoin tidak bisa andal menerapkan akuntabilitas fork, selain yang implisit biaya peluang yang dibayarkan oleh penambang untuk menambang blok yatim piatu. Kami menyebut tahapan pemungutan suara PreVote dan PreCommit. Pemungutan suara bisa untuk blok tertentu atau untuk Nil. Kami menyebutnya kumpulan >⅔ PreVotes untuk satu blok di babak yang sama sebuah Polka, dan kumpulan >⅔ PreCommits untuk satu blok di putaran yang sama dengan Commit. Jika >⅔ PreCommit untuk Nil di babak yang sama, mereka melanjutkan ke babak berikutnya bulat. Perhatikan bahwa determinisme yang ketat dalam protokol menimbulkan kelemahan asumsi sinkronisasi sebagai pemimpin yang salah harus dideteksi dan

dilewati. Jadi, validators menunggu beberapa saat, TimeoutUsulkan, sebelum mereka Prevote Nil, dan nilai TimeoutPropose meningkat pada setiap putaran. Kemajuan melalui sisa putaran sepenuhnya tidak sinkron, hanya kemajuan yang ada dibuat setelah validator mendengar dari >⅔ jaringan. Dalam praktiknya, dibutuhkan musuh yang sangat kuat untuk menggagalkannya tanpa batas waktu asumsi sinkronisasi yang lemah (menyebabkan gagalnya konsensus pernah melakukan satu blok), dan hal itu dapat dilakukan lebih banyak lagi kesulitan dengan menggunakan nilai acak TimeoutPropose pada masing-masingnya validator. Serangkaian batasan tambahan, atau Aturan Penguncian, memastikan bahwa jaringan pada akhirnya akan melakukan hanya satu blok pada setiap ketinggian. Apa saja upaya jahat untuk menyebabkan lebih dari satu blok dilakukan pada ketinggian tertentu dapat diidentifikasi. Pertama, PreCommit untuk sebuah blok harus disertai justifikasi berupa Polka untuk blok tersebut. Jika validator telah melakukan PreCommit satu blok pada putaran R_1, kita mengatakan mereka dikunci di blok itu, dan Polka biasa membenarkannya PreCommit baru pada putaran R_2 harus terjadi pada putaran R_polka dimana R_1 < R_polka <= R_2. Kedua, validators harus Mengusulkan dan/atau melakukan PreVote pada blok tempat mereka dikunci. Bersama-sama, ini ketentuan memastikan bahwa validator tidak melakukan PreCommit tanpanya bukti yang cukup sebagai pembenaran, dan validators yang memiliki sudah PreCommit tidak dapat memberikan kontribusi bukti kepada PreCommit sesuatu yang lain. Hal ini menjamin keamanan dan keaktifan algoritma konsensus. Rincian lengkap protokol dijelaskan di sini. Kebutuhan untuk menyinkronkan semua header blok dihilangkan di TendermintPoS karena keberadaan rantai alternatif (garpu) berarti ≥⅓ dari pasak terikat dapat dipangkas. Tentu saja, karena pemotongan memerlukan bahwa seseorang berbagi bukti garpu, klien ringan harus menyimpannya setiap blok-hash melakukan apa yang dilihatnya. Selain itu, klien ringandapat tetap tersinkronisasi secara berkala dengan perubahan pada kumpulan validator, di untuk menghindari serangan jarak jauh (tetapi solusi lain bisa mungkin). Dengan semangat yang mirip dengan Ethereum, Tendermint memungkinkan aplikasi untuk sematkan akar Merkle global hash di setiap blok, sehingga mudah pertanyaan status yang dapat diverifikasi untuk hal-hal seperti saldo akun, nilainya disimpan dalam kontrak, atau adanya transaksi yang tidak terpakai keluarannya, tergantung pada sifat aplikasinya. Dengan asumsi kumpulan jaringan siaran cukup tangguh dan set validator statis, garpu apa pun di blockchain dapat berupa terdeteksi dan simpanan validator yang melanggar dipotong. Ini Inovasi yang pertama kali disarankan oleh Vitalik Buterin pada awal tahun 2014, berhasil memecahkan masalah tersebut masalah tidak ada yang dipertaruhkan dari proof-of-stake lainnya cryptocurrency (lihat Pekerjaan Terkait). Namun, sejak validator ditetapkan harus dapat berubah, dalam jangka waktu yang lama, yang asli validators semuanya dapat menjadi tidak terikat, dan karenanya akan bebas untuk terikat membuat rantai baru dari blok genesis, tanpa biaya mereka tidak lagi menyimpan simpanan. Serangan ini terjadi dikenal sebagai Long Range Attack (LRA), berbeda dengan Short Range Attack, dimana validator yang sedang terikat menyebabkan a garpu dan karenanya dapat dihukum (dengan asumsi BFT yang bertanggung jawab atas garpu algoritma seperti konsensus Tendermint). Serangan Jarak Jauh adalah sering dianggap sebagai pukulan telak bagi proof-of-stake. Untungnya, LRA dapat dimitigasi dengan cara berikut. Pertama, untuk a validator untuk melepas ikatan (sehingga memulihkan simpanan jaminan mereka dan tidak lagi mendapatkan bayaran untuk berpartisipasi dalam konsensus), itu deposit harus dibuat tidak dapat dipindahtangankan untuk jangka waktu tertentu dikenal sebagai “periode tidak terikat”, yang mungkin terjadi pada urutan minggu atau bulan. Kedua, agar klien ringan aman, pertama kali terhubung ke jaringan, ia harus memverifikasi blok terbaru-hash terhadap sumber terpercaya, atau sebaiknya beberapa sumber. Ini

kondisi ini kadang-kadang disebut sebagai “subjektivitas lemah”. Akhirnya, agar tetap aman, harus disinkronkan dengan validator terbaru yang disetel pada paling tidak sesering lamanya periode pelepasan ikatan. Ini memastikan bahwa klien ringan mengetahui tentang perubahan pada validator ditetapkan sebelum validator modalnya tidak terikat sehingga tidak lagi dipertaruhkan, yang memungkinkannya menipu klien dengan melakukan serangan jarak jauh dengan membuat blok baru dimulai dari a ketinggian tempat ia diikat (dengan asumsi ia memiliki kendali yang cukup banyak kunci pribadi awal). Perlu dicatat bahwa mengatasi LRA dengan cara ini memerlukan perombakan model keamanan asli proof-of-work. Di PoW, memang demikian diasumsikan bahwa klien ringan dapat melakukan sinkronisasi ke ketinggian saat ini dari blok genesis tepercaya kapan saja hanya dengan memproses bukti kerja di setiap header blok. Namun, untuk mengatasi LRA, kami mengharuskan klien ringan untuk online secara teratur lacak perubahan di set validator, dan itu untuk pertama kalinya saat online, mereka harus sangat berhati-hati dalam mengautentikasi apa yang mereka dengar dari jaringan terhadap sumber terpercaya. Dari Tentu saja, persyaratan terakhir ini mirip dengan Bitcoin, dimana protokol dan softwarenya juga harus didapat dari yang terpercaya sumber. Metode pencegahan LRA di atas sangat cocok untuk validators dan node penuh dari blockchain yang didukung Tendermint karena ini node dimaksudkan untuk tetap terhubung ke jaringan. Itu Metode ini juga cocok untuk klien ringan yang diharapkan dapat melakukannya sering melakukan sinkronisasi dengan jaringan. Namun, untuk klien ringan itu diharapkan tidak sering mengakses internet atau blockchain jaringan, solusi lain dapat digunakan untuk mengatasinya LRA. Pemegang non-validator token dapat memposting token mereka sebagai agunan dengan jangka waktu pelepasan ikatan yang sangat lama (misalnya lebih lama dari periode pelepasan ikatan selama validators) dan melayani klien ringan dengan metode sekunder untuk membuktikan validitas saat ini dan blok terakhir-hashes. Meskipun token ini tidak diperhitungkan demi keamanan konsensus blockchain, mereka tetap bisa melakukannyamemberikan jaminan yang kuat untuk klien ringan. Jika blok historis-hash kueri didukung di Ethereum, siapa pun dapat menyatukannya tokens dalam smart contract yang dirancang khusus dan disediakan layanan pengesahan dengan bayaran, yang secara efektif menciptakan pasar untuk keamanan LRA klien ringan. Karena definisi dari komitmen blok, setiap ≥⅓ koalisi dari hak suara dapat menghentikan blockchain dengan membuka zine atau tidak menyiarkan suara mereka. Koalisi seperti itu juga bisa melakukan sensor transaksi tertentu dengan menolak blok yang mencakup ini transaksi, meskipun hal ini akan menghasilkan proporsi yang signifikan proposal blok yang akan ditolak, yang akan memperlambat lajunya blok melakukan blockchain, mengurangi utilitas dan nilainya. Koalisi jahat mungkin juga menyiarkan suara secara perlahan untuk mengerjakan blockchain blok yang hampir dihentikan, atau terlibat kombinasi serangan ini. Pada akhirnya, hal ini dapat menyebabkan blockchain melakukan percabangan, dengan menandatangani dua kali atau melanggar penguncian aturan. Jika musuh yang aktif secara global juga terlibat, hal ini dapat terpecah jaringan sedemikian rupa sehingga mungkin tampak salah subset dari validators bertanggung jawab atas perlambatan ini. Ini tidak hanya batasan Tendermint, melainkan batasan semuanya protokol konsensus yang jaringannya berpotensi dikendalikan oleh musuh aktif. Untuk jenis serangan ini, subset dari validator seharusnya berkoordinasi melalui sarana eksternal untuk menandatangani proposal reorg itu memilih garpu (dan bukti apa pun daripadanya) dan bagian awal dari validators dengan tanda tangannya. Validator yang menandatangani proposal reorganisasi tersebut melepaskan jaminan mereka pada semua fork lainnya. Klien harus memverifikasi tanda tangan pada proposal reorg, memverifikasi bukti apa pun, dan membuat penilaian atau meminta pengguna akhir untuk mengambil keputusan. Untuk Misalnya, aplikasi dompet telepon mungkin meminta keamanan kepada pengguna

peringatan, sementara lemari es dapat menerima proposal reorg apa pun ditandatangani oleh +½ dari validator asli dengan hak suara. Tidak ada algoritma toleransi kesalahan Bizantium yang tidak sinkron untuk mencapai konsensus ketika ≥⅓ hak suara tidak jujur, namun merupakan sebuah fork berasumsi bahwa ≥⅓ hak suara telah dilakukan secara tidak jujur penandatanganan ganda atau pengubahan kunci tanpa alasan yang sah. Jadi, penandatanganan usulan reorg adalah masalah koordinasi yang tidak bisa dilakukan diselesaikan oleh protokol non-sinkron apa pun (yaitu secara otomatis, dan tanpa membuat asumsi tentang keandalannya jaringan yang mendasarinya). Untuk saat ini, kami menyerahkan masalah koordinasi reorganisasi proposal kepada koordinasi manusia melalui konsensus sosial di media internet. Validator harus berhati-hati untuk memastikan hal itu ada tidak ada partisi jaringan yang tersisa sebelum menandatangani proposal reorg, untuk menghindari situasi ketika dua proposal reorg yang saling bertentangan ditandatangani. Dengan asumsi bahwa media dan protokol koordinasi eksternal adalah kuat, maka fork tidak terlalu memprihatinkan dibandingkan sensor serangan. Selain garpu dan sensor, yang membutuhkan ≥⅓ Bizantium kekuatan suara, koalisi dengan >⅔ kekuatan suara dapat berkomitmen sewenang-wenang, keadaan tidak valid. Ini adalah karakteristik dari setiap (BFT) sistem konsensus. Berbeda dengan penandatanganan ganda yang menimbulkan percabangan dengan bukti yang mudah diverifikasi, mendeteksi komitmen suatu keadaan tidak valid memerlukan rekan yang tidak memvalidasi untuk memverifikasi seluruh blok, yang menyiratkan bahwa mereka menyimpan salinan lokal negara bagian dan mengeksekusinya setiap transaksi, menghitung root status secara independen diri mereka sendiri. Setelah terdeteksi, satu-satunya cara untuk menangani kegagalan tersebut adalah melalui konsensus sosial. Misalnya, dalam situasi di mana Bitcoin telah gagal, baik forking karena bug perangkat lunak (seperti pada bulan Maret 2013), atau melakukan status tidak sah karena perilaku Bizantium penambang (seperti pada Juli 2015), komunitas yang terhubung dengan baik bisnis, pengembang, penambang, dan organisasi lainnya menetapkan konsensus sosial mengenai tindakan manual apa yang dimaksuddibutuhkan oleh peserta untuk menyembuhkan jaringan. Terlebih lagi, sejak itu validators dari Tendermint blockchain mungkin diharapkan dapat diidentifikasi, komitmen negara yang tidak valid bahkan mungkin dapat dihukum oleh hukum atau yurisprudensi eksternal, jika diinginkan. ABCI terdiri dari 3 jenis pesan utama yang dikirimkan inti dari aplikasi tersebut. Aplikasi membalas dengan pesan respons yang sesuai. Pesan  AppendTx  adalah kerangka kerja aplikasi. Masing-masing transaksi di blockchain dikirimkan dengan pesan ini. Itu aplikasi perlu memvalidasi setiap transaksi yang diterima dengan Pesan AppendTx terhadap status saat ini, protokol aplikasi, dan kredensial kriptografi transaksi. Sebuah divalidasi transaksi kemudian perlu memperbarui status aplikasi — oleh mengikat suatu nilai ke dalam penyimpanan nilai kunci, atau dengan memperbarui UTXO basis data. Pesan  CheckTx  mirip dengan AppendTx, namun hanya untuk memvalidasi transaksi. Pemeriksaan mempool Tendermint Core pertama kali validitas transaksi dengan CheckTx, dan hanya relay yang valid transaksi ke rekan-rekannya. Aplikasi mungkin memeriksa peningkatan nonce dalam transaksi dan mengembalikan kesalahan pada CheckTx jika nonce sudah tua. Pesan  Commit  digunakan untuk menghitung kriptografi komitmen terhadap status aplikasi saat ini, untuk ditempatkan ke dalam header blok berikutnya. Ini memiliki beberapa properti berguna. Inkonsistensi dalam memperbarui status tersebut kini akan muncul sebagai blockchain fork yang menangkap seluruh kelas pemrograman kesalahan. Ini juga menyederhanakan pengembangan kelas ringan yang aman klien, sebagai bukti Merkle-hash dapat diverifikasi dengan melakukan pengecekan blok-hash, dan blok-hash ditandatangani oleh kuorum validators (berdasarkan hak suara).

Pesan ABCI tambahan memungkinkan aplikasi untuk melacaknya dan mengubah set validator, dan agar aplikasi menerima memblokir informasi, seperti tinggi dan suara komit. ABCI permintaan/tanggapan adalah pesan Protobuf sederhana. Periksa keluar skema yle. Argumen: Data ([]byte) : Byte transaksi permintaan Pengembalian: Kode (uint32) : Kode respons Data ([]byte) : Byte hasil, jika ada Log (string): Pesan debug atau error Penggunaan:

Tambahkan dan jalankan transaksi. Jika transaksinya sah, mengembalikan CodeType.OK Argumen: Data ([]byte) : Byte transaksi permintaan Pengembalian: Kode (uint32) : Kode respons Data ([]byte) : Byte hasil, jika ada Log (string): Pesan debug atau error Penggunaan:

Validasi transaksi. Pesan ini tidak boleh mengubah negara bagian. Transaksi pertama kali dijalankan melalui CheckTx sebelumnya disiarkan ke rekan-rekan di lapisan mempool. Anda bisa membuat CheckTx semi-stateful dan hapus status saat Komit atau BeginBlock , untuk memungkinkan urutan transaksi yang bergantung di blok yang sama.

Pengembalian: Data ([]byte): Akar Merkle hash Log (string): Pesan debug atau error Penggunaan:

Mengembalikan akar Merkle hash dari status aplikasi. Argumen: Data ([]byte) : Byte permintaan kueri Pengembalian: Kode (uint32) : Kode respons Data ([]byte) : Byte respons kueri Log (string): Pesan debug atau error Penggunaan:

Hapus antrian respons. Aplikasi yang mengimplementasikan jenis.Aplikasi tidak perlu mengimplementasikan pesan ini – itu ditangani oleh proyek tersebut. Pengembalian: Data ([]byte) : Byte info Penggunaan:

Kembalikan informasi tentang status aplikasi. Aplikasi spesifik. Argumen: Kunci (string) : Kunci untuk disetel

Nilai (string): Nilai yang akan ditetapkan untuk kunci Pengembalian: Log (string): Pesan debug atau error Penggunaan:

Tetapkan opsi aplikasi. Misalnya. Kunci=“mode”, Nilai=“mempool” untuk koneksi mempool, atau Key=“mode”, Value=“konsensus” untuk hubungan konsensus. Pilihan lainnya adalah aplikasi spesifik. Argumen: Validator ([]Validator) : Kejadian awal-validators Penggunaan:

Dipanggil sekali pada saat kejadian Argumen: Tinggi (uint64) : Tinggi balok yang dimulai Penggunaan:

Menandakan dimulainya blok baru. Dipanggil sebelum apa pun TambahkanTxs. Argumen: Tinggi (uint64) : Tinggi blok yang berakhir Pengembalian: Validator ([]Validator) : Mengubah validator dengan yang baru hak suara (0 untuk menghapus) Penggunaan:

Menandakan akhir dari sebuah blok. Bagaimanapun juga, dipanggil sebelum setiap Komit transaksi Lihat repositori ABCI untuk lebih jelasnya.Ada beberapa alasan mengapa pengirim mungkin menginginkannya pengakuan pengiriman paket oleh rantai penerima. Misalnya, pengirim mungkin tidak mengetahui statusnya rantai tujuan, jika diperkirakan salah. Atau, pengirimnya mungkin ingin menerapkan batas waktu pada paket (dengan metode  MaxHeight  paket yeld), sementara rantai tujuan mana pun mungkin mengalami serangan penolakan layanan dengan lonjakan jumlah pesan masuk secara tiba-tiba paket. Dalam kasus ini, pengirim dapat meminta pengakuan pengiriman dengan menyetel status paket awal ke  AckPending . Lalu, itu adalah tanggung jawab rantai penerima untuk mengonfirmasi pengiriman dengan menyertakan disingkat IBCPacket  di aplikasi Merkle hash. Pertama, IBCBlockCommit  dan  IBCPacketTx  diposting di “Hub” yang membuktikan keberadaan IBCPaket  di “Zona1”. Katakan itu  IBCPacketTx  memiliki nilai berikut: FromChainID : “Zona1” FromBlockHeight : 100 (katakanlah) Paket : sebuah IBCPaket :

Tajuk : dan IBCPacketHeader : SrcChainID : “Zona1” DstChainID : “Zona2” Nomor : 200 (katakanlah) Status : AckPending Ketik : “koin” MaxHeight : 350 (misalnya “Hub” saat ini berada pada ketinggian 300) Payload : Selanjutnya, IBCBlockCommit  dan  IBCPacketTx  diposting di “Zone2” yang membuktikan adanya IBCPacket  di “Hub”. Katakan itu  IBCPacketTx  memiliki nilai berikut: DariChainID : “Hub” DariBlockHeight : 300 Paket : sebuah IBCPaket : Tajuk : dan IBCPacketHeader : SrcChainID : “Zona1” DstChainID : “Zona2” Nomor : 200 Status : AckPending Ketik : “koin” Tinggi Maks: 350 Payload : Selanjutnya, “Zona2” harus menyertakan dalam aplikasinya-hash paket yang disingkat yang menunjukkan status baru  AckSent . Sebuah IBCBlockCommit  dan  IBCPacketTx  diposting kembali di “Hub” yang membuktikan keberadaannya dari singkatan IBCPacket  pada "Zona2". Ucapkan IBCPacketTx  mempunyai nilai sebagai berikut: FromChainID : “Zona2”

FromBlockHeight : 400 (katakanlah) Paket : sebuah IBCPaket : Tajuk : dan IBCPacketHeader : SrcChainID : “Zona1” DstChainID : “Zona2” Nomor : 200 Status : AckSent Ketik : “koin” Tinggi Maks: 350 PayloadHash : Terakhir, “Hub” harus memperbarui status paket dari  AckPending  ke  AckReceived . Bukti dari status ynalisasi baru ini harus kembali ke "Zona2". Katakanlah IBCPacketTx  memiliki yang berikut ini nilai: DariChainID : “Hub” DariBlockHeight : 301 Paket : sebuah IBCPaket : Tajuk : dan IBCPacketHeader : SrcChainID : “Zona1” DstChainID : “Zona2” Nomor : 200 Status : Diterima Ketik : “koin” Tinggi Maks: 350 PayloadHash : Sementara itu, “Zona 1” mungkin secara optimis memperkirakan keberhasilan pengiriman dari paket "koin" kecuali terbukti sebaliknya “Pusat”. Pada contoh di atas, jika “Hub” belum menerima  AckSent

status dari “Zona2” di blok 350, itu akan mengatur statusnya secara otomatis ke  Waktu Habis . Bukti batas waktu ini bisa didapat diposting kembali di “Zona1”, dan token apa pun dapat dikembalikan. Ada dua jenis Merkle tree yang didukung di Ekosistem Tendermint/Cosmos: Pohon Sederhana, dan IAVL+ Pohon. Pohon Sederhana adalah Merkle tree untuk daftar elemen statis. Jika jumlah item bukan pangkat dua, beberapa daun akan ada tingkat yang berbeda. Simple Tree mencoba menjaga kedua sisi pohon tetap sama tingginya sama, tapi yang kiri mungkin lebih besar. Merkle tree ini adalah digunakan untuk Merkle-ize transaksi suatu blok, dan tingkat atas elemen root status aplikasi.Tujuan dari struktur data IAVL+ adalah untuk menyediakan persisten penyimpanan untuk pasangan nilai kunci dalam status aplikasi sedemikian rupa sehingga a Akar Merkle deterministik hash dapat dihitung secara efisien. Itu pohon diseimbangkan menggunakan varian algoritma AVL, dan semuanya operasinya adalah O(log(n)). Dalam pohon AVL, tinggi dua subpohon anak dari setiap node berbeda paling banyak satu. Setiap kali kondisi ini dilanggar pada suatu diperbarui, pohon diseimbangkan kembali dengan membuat O(log(n)) node baru itu menunjuk ke simpul pohon tua yang tidak dimodifikasi. Dalam AVL asli algoritma, node dalam juga dapat menampung pasangan nilai kunci. AVL+ algoritma (perhatikan plusnya) memodifikasi algoritma AVL untuk menyimpan semuanya nilai pada node daun, sementara hanya menggunakan node cabang untuk menyimpan kunci. Ini menyederhanakan algoritma sambil menjaga jejak merkle hash pendek. Pohon AVL+ analog dengan percobaan Patricia Ethereum. Ada pengorbanan. Kunci tidak perlu hash sebelum dimasukkan Pohon IAVL+, sehingga memberikan iterasi terurut yang lebih cepat pada kunci ruang yang mungkin menguntungkan beberapa aplikasi. Logikanya lebih sederhana implementasi, hanya membutuhkan dua jenis node – node dalam dan simpul daun. Bukti Merkle rata-rata lebih pendek, yaitu a                 *                 / \               /     \             /         \           /             \          *              >         / \            //\        /   \           /   \       /     \         /     \      +     / \     / \    //\    h0  h1  h2  h3  h4  h5    Sebuah SimpleTree dengan 7 elemen

pohon biner seimbang. Di sisi lain, akar Merkle dari an Pohon IAVL+ bergantung pada urutan pembaruan. Kami akan mendukung Merkle tree tambahan yang efisien, seperti Patricia Trie Ethereum saat varian biner menjadi tersedia. Dalam implementasi kanonik, transaksi dialirkan ke Cosmos aplikasi hub melalui antarmuka ABCI. Hub Cosmos akan menerima sejumlah transaksi utama jenisnya, termasuk  SendTx ,  BondTx ,  UnbondTx ,  ReportHackTx ,  SlashTx, BurnAtomTx,ProposalCreateTx, dan `ProposalVoteTx, yang cukup jelas dan akan didokumentasikan dalam a revisi masa depan makalah ini. Di sini kami mendokumentasikan dua hal utama jenis transaksi untuk IBC:  IBCBlockCommitTx  dan  IBCPacketTx . Transaksi  IBCBlockCommitTx  terdiri dari: ChainID (string): ID blockchain BlockHash ([]byte) : Blok-hash byte, akar Merkle yang mencakup aplikasi-hash BlockPartsHeader (PartSetHeader) : Header kumpulan bagian blok byte, hanya diperlukan untuk memverifikasi tanda tangan suara BlockHeight (int) : Ketinggian penerapan BlockRound (int) : Putaran penerapan Commit ([]Vote): >⅔ Tendermint Precommit memberikan suara tersebut terdiri dari komit blok ValidatorsHash ([]byte) : Akar pohon Merkle hash yang baru validator disetel

ValidatorsHashProof (SimpleProof): SimpleTree Merkleproof untuk membuktikan ValidatorsHash terhadap BlockHash AppHash ([]byte) : Akar pohon Merkle IAVLTree hash dari keadaan aplikasi AppHashProof (SimpleProof): SimpleTree Merkle-proof untuk membuktikan AppHash terhadap BlockHash Sebuah IBCPaket  terdiri dari: Header (IBCPacketHeader) : Header paket Payload ([]byte) : Byte payload paket. Opsional PayloadHash ([]byte) : hash untuk byte paket. Opsional Salah satu dari  Payload  atau  PayloadHash  harus ada. hash dari IBCPacket  adalah akar Merkle sederhana dari dua item,  Header  dan  Muatan . Sebuah IBCPaket  tanpa muatan penuh disebut an paket yang disingkat.  IBCPacketHeader  terdiri dari: SrcChainID (string) : ID blockchain sumber DstChainID (string) : ID blockchain tujuan Nomor (int) : Nomor unik untuk semua paket Status (enum): Dapat berupa salah satu dari AckPending , AckSent , AckReceived , NoAck , atau Timeout Type (string) : Jenisnya bergantung pada aplikasi. Cosmos memesan jenis paket "koin". MaxHeight (int) : Jika statusnya bukan NoAckWanted atau AckReceived pada ketinggian ini, status menjadi Timeout . Opsional Transaksi  IBCPacketTx  terdiri dari:FromChainID (string) : ID dari blockchain yaitu menyediakan paket ini; belum tentu sumbernya FromBlockHeight (int) : Ketinggian blockchain di mana paket berikut disertakan (merkle-ized) di blok-hash dari rantai sumber Paket (IBCPaket) : Paket data, yang statusnya mungkin satu dari AckPending , AckSent , AckReceived , NoAck , atau Timeout PacketProof (IAVLProof): IAVLTree Merkle-proof untuk pembuktian hash paket terhadap AppHash dari rantai sumber di ketinggian tertentu Urutan pengiriman paket dari “Zone1” ke “Zone2” melalui "Hub" digambarkan pada {Gambar X}. Pertama, IBCPacketTx  membuktikan kepada "Hub" bahwa paket tersebut termasuk dalam status aplikasi “Zona 1”. Kemudian, IBCPacketTx  lainnya membuktikan kepada “Zona2” bahwa paket disertakan dalam status aplikasi "Hub". Selama ini prosedurnya, hasil IBCPacket  sama:  SrcChainID  adalah selalu “Zona1”, dan  DstChainID  selalu "Zona2".  PacketProof  harus memiliki jalur anti Merkle yang benar, misalnya berikut: Ketika “Zone1” ingin mengirim paket ke “Zone2” melalui “Hub”, data IBCPacket  tetap identik, baik paket tersebut Merkleisasi di “Zone1”, “Hub”, atau “Zone2”. Satu-satunya teriakan yang bisa berubah adalah  Status  untuk melacak pengiriman. Kami berterima kasih kepada teman-teman dan rekan-rekan kami atas bantuannya dalam membuat konsep, meninjau, dan memberikan dukungan untuk pekerjaan kami dengan Tendermint dan Cosmos. IBC///

Zaki Manian dari SkuChain memberikan banyak bantuan dalam pemformatan dan kata-katanya, terutama di bawah bagian ABCI Jehan Tremback dari Althea dan Dustin Byington atas bantuannya iterasi awal Andrew Miller dari Honey Badger atas masukan mengenai konsensus Greg Slepak atas umpan balik mengenai konsensus dan penyusunan kata-kata Juga terima kasih kepada Bill Gleim dan Seunghwan Han untuk berbagai hal kontribusi. Nama dan organisasi Anda di sini atas kontribusi Anda 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 Nol Tunai: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Saksi Terpisah: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Jaringan Petir: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 permen lembut: https://github.com/tendermint/tendermint/wiki 9 Ketidakmungkinan FLP: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Pemotong: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 BitShare: https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Buku Besar: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 Rantai Samping: https://blockstream.com/sidechains.pdf 16Kasper: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Pembagian: https://github.com/ethereum/EIPs/issues/53 19LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysisOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 Keamanan Klien Tipis: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Kertas Ungu Muda: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

³ ya