Protokol Konsensus Stellar
Abstrak
Pembayaran internasional lambat dan mahal, sebagian karena jalur pembayaran multi-hop yang heterogen sistem perbankan. Stellar adalah jaringan pembayaran global baru yang dapat langsung mentransfer uang digital ke mana pun di dunia dunia dalam hitungan detik. Inovasi kuncinya adalah transaksi yang aman mekanisme di perantara yang tidak tepercaya, menggunakan yang baru Protokol perjanjian Bizantium disebut SCP. Dengan SCP, masing-masing institusi menentukan institusi lain yang akan tetap tinggal setuju; melalui keterhubungan global sistem keuangan, seluruh jaringan kemudian menyetujui atom transaksi yang mencakup institusi sewenang-wenang, tanpa solvabilitas atau risiko nilai tukar dari penerbit aset perantara atau pembuat pasar. Kami menyajikan model, protokol, dan verifikasi formal; jelaskan jaringan pembayaran Stellar; dan terakhir mengevaluasi Stellar secara empiris melalui tolok ukur dan pengalaman kami dengan beberapa tahun penggunaan produksi. Konsep CCS • Keamanan dan privasi → Terdistribusi keamanan sistem; • Organisasi sistem komputer → Arsitektur peer-to-peer; • Sistem informasi → Transfer dana elektronik. Kata kunci blockchain, BFT, kuorum, pembayaran Format Referensi ACM: Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, Jed McCaleb. 2019. Pembayaran global yang cepat dan aman dengan Stellar. Di SOSP '19: Simposium Prinsip Sistem Operasi, 27-30 Oktober, 2019, Huntsville, ON, Kanada. ACM, New York, NY, AS, 17 halaman. https://doi.org/10.1145/3341301.3359636
Perkenalan
Pembayaran internasional terkenal lambat dan mahal [32]. Pertimbangkan ketidakpraktisan pengiriman $0,50 dari AS ke * Galois, Inc. †UCLA Izin untuk membuat salinan digital atau cetak dari seluruh atau sebagian karya ini penggunaan pribadi atau ruang kelas diberikan tanpa biaya asalkan salinannya tidak dibuat atau didistribusikan untuk keuntungan atau keuntungan komersial dan salinannya mempunyai hakikat pemberitahuan ini dan kutipan lengkap di halaman pertama. Hak cipta untuk komponen karya ini dimiliki oleh orang lain selain ACM harus dihormati. Mengabstraksi dengan kredit diperbolehkan. Untuk menyalin sebaliknya, atau menerbitkan ulang, untuk memposting di server atau ke mendistribusikan ulang ke daftar, memerlukan izin khusus sebelumnya dan/atau biaya. Permintaan izin dari [email protected]. SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada © 2019 Asosiasi Mesin Komputasi. ACM ISBN 978-1-4503-6873-5/19/10...$15.00 https://doi.org/10.1145/3341301.3359636 Meksiko, dua negara tetangga. Pengguna akhir membayar hampir $9 untuk rata-rata transfer tersebut [32], dan perjanjian bilateral yang ditengahi oleh bank sentral negara-negara tersebut hanya dapat mengurangi biaya bank yang mendasarinya menjadi $0,67 per item [2]. Selain biaya, latensi pembayaran internasional umumnya dihitung dalam hitungan hari, sehingga tidak mungkin mendapatkan uang ke luar negeri dengan cepat keadaan darurat. Di negara-negara yang sistem perbankannya tidak memilikinya bekerja atau tidak melayani semua warga negara, atau ketika biaya tidak dapat ditoleransi, masyarakat terpaksa mengirimkan pembayaran dengan bus [38], dengan perahu [19], dan kadang-kadang sekarang Bitcoin [55], semuanya menimbulkan risiko, latensi, atau ketidaknyamanan. Meskipun akan selalu ada biaya kepatuhan, bukti menunjukkan bahwa sejumlah besar kerugian disebabkan oleh kurangnya persaingan [21], yang diperburuk oleh teknologi yang tidak efisien. Dimana orang dapat berinovasi, harga dan latensi turun. Misalnya, biaya pengiriman uang dari rekening bank pada Q2 2019 rata-rata sebesar 6,99%, sedangkan uang seluler hanya 4,88% [13]. Jaringan pembayaran global terbuka yang menarik inovasi dan persaingan dari entitas non-bank dapat menurun biaya dan latensi di semua lapisan, termasuk kepatuhan [83]. Makalah ini menyajikan Stellar, pembayaran berbasis blockchain jaringan yang dirancang khusus untuk memfasilitasi inovasi dan persaingan dalam pembayaran internasional. Stellar adalah yang pertama sistem untuk memenuhi ketiga tujuan berikut (di bawah a “Hipotesis Internet” yang baru namun valid secara empiris): 1. Keanggotaan terbuka – Siapapun dapat menerbitkan mata uang yang didukung tokens digital yang dapat dipertukarkan antar pengguna. 2. Finalitas yang diberlakukan oleh penerbit – Penerbit token dapat mencegah transaksi di token agar tidak dibalik atau dibatalkan. 3. Atomisitas lintas penerbit – Pengguna dapat bertukar secara atom dan perdagangkan token dari beberapa penerbit. Mencapai dua yang pertama itu mudah. Perusahaan mana pun dapat secara sepihak menawarkan produk seperti Paypal, Venmo, WeChat Bayar, atau Alipay dan pastikan finalitas pembayaran di mata uang virtual yang mereka buat. Sayangnya, bertransaksi secara atomik antar mata uang ini tidak mungkin dilakukan. Faktanya, meskipun Paypal telah mengakuisisi perusahaan induk Venmo pada tahun 2013, pengguna akhir masih tidak dapat mengirim Venmo dolar ke pengguna Paypal [78]. Baru belakangan ini pedagang bisa bahkan menerima keduanya dengan satu integrasi. Tujuan 2 dan 3 dapat dicapai dalam sistem tertutup. Secara khusus, sejumlah negara memiliki pembayaran domestik yang efisien jaringan, biasanya diawasi oleh otoritas pengatur yang dipercaya secara universal. Namun keanggotaannya terbatas dan tertutup kumpulan bank yang disewa dan jaringannya terbatas pada jangkauan otoritas pengatur suatu negara.SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. Sasaran 1 dan 3 telah tercapai dalam blockchains, terutama dalam bentuk ERC20 tokens pada Ethereum [3]. Ide utama dari blockchain ini adalah untuk menciptakan mata uang kripto baru yang dapat digunakan untuk memberikan penghargaan kepada orang-orang yang telah menyelesaikan pekerjaan mereka. transaksi sulit untuk dikembalikan. Sayangnya, ini berarti penerbit token tidak mengontrol penyelesaian transaksi. Jika perangkat lunak kesalahan menyebabkan riwayat transaksi diatur ulang [26, 73], atau ketika keuntungan yang diperoleh orang yang menipu melebihi biayanya mengatur ulang sejarah [74, 97], penerbit mungkin bertanggung jawab atas tokens mereka telah menebusnya dengan uang dunia nyata. Stellar blockchain memiliki dua sifat yang membedakan. Pertama, ini secara asli mendukung pasar yang efisien antara tokens dari emiten yang berbeda. Secara khusus, siapa pun dapat menerbitkan token, blockchain menyediakan buku pesanan bawaan untuk perdagangan antara pasangan token mana pun, dan pengguna dapat mengeluarkan pembayaran jalur yang secara atom memperdagangkan beberapa pasangan mata uang sementara menjamin harga batas ujung ke ujung. Kedua, Stellar memperkenalkan perjanjian Bizantium baru protokol, SCP (Stellar Protokol Konsensus), yang melaluinya token penerbit menunjuk server validator tertentu untuk diterapkan finalitas transaksi. Selama tidak ada seorang pun yang mengkompromikan validator penerbit (dan tanda tangan digital yang mendasarinya serta kriptografi hashes tetap aman), penerbit tahu persis transaksi mana yang telah terjadi dan menghindari risiko kerugian dari blockchain sejarah reorganisasi. Ide utama SCP adalah agar sebagian besar penerbit aset mendapatkan keuntungan darinya pasar likuid dan ingin memfasilitasi transaksi atom dengan aset lainnya. Oleh karena itu, validator administrator mengonfigurasi server mereka setuju dengan validator lainnya sejarah semua transaksi pada semua aset. validator v1 bisa dikonfigurasi untuk menyetujui v2, atau v2 dapat dikonfigurasi untuk menyetujui dengan v1, atau keduanya dapat dikonfigurasi agar sesuai satu sama lain; dalam semua kasus, tidak ada yang akan berkomitmen pada riwayat transaksi sampai ia tahu pihak lain tidak dapat berkomitmen pada sejarah yang berbeda. Secara transitivitas, jika v1 tidak bisa tidak setuju dengan v2 dan v2 tidak bisa tidak setuju dengan v3 (atau sebaliknya), v1 tidak bisa tidak setuju dengan v3, apakah v3 mewakili aset v1 atau tidak dari. Berdasarkan hipotesis bahwa hubungan perjanjian ini menghubungkan seluruh jaringan secara transitif, jaminan SCP perjanjian global, menjadikannya perjanjian Bizantium global protokol dengan keanggotaan terbuka. Kami menyebut asumsi keterhubungan baru ini sebagai hipotesis Internet, dan mencatatnya sebagai hipotesis memegang kedua "Internet" (yang semua orang memahaminya berarti jaringan IP terbesar yang terhubung secara transitif) dan pembayaran internasional lama (yang bersifat hop-by-hop non-atom, namun memanfaatkan koneksi global yang bersifat transitif jaringan lembaga keuangan). Stellar telah digunakan produksi sejak September 2015. Agar panjang blockchain dapat dikelola, sistem berjalan SCP dengan interval 5 detik—cepat dengan standar blockchain, tapi jauh lebih lambat dibandingkan penerapan perjanjian Bizantium pada umumnya. Meskipun penggunaan utamanya adalah pembayaran, Stellar juga demikian terbukti menarik bagi token non-uang yang menguntungkan dari pasar sekunder terdekat (lihat Bagian 7.1). Bagian selanjutnya membahas pekerjaan terkait. Bagian 3 menyajikan SCP. Bagian 4 menjelaskan verifikasi formal kami terhadap SCP. Bagian 5 menjelaskan lapisan pembayaran Stellar. Bagian 6 berhubungan beberapa pengalaman penerapan dan pembelajaran kami. Bagian 7 mengevaluasi sistem. Bagian 8 menyimpulkan.
Stellar protokol konsensus
Protokol konsensus Stellar (SCP) berbasis kuorum Protokol perjanjian Bizantium dengan keanggotaan terbuka. Kuorum muncul dari keputusan konfigurasi lokal gabungan dari masing-masing node. Namun, node hanya mengenali kuorum di mana mereka menjadi anggotanya, dan hanya setelahnya mempelajari konfigurasi lokal dari semua anggota kuorum lainnya. Salah satu manfaat dari pendekatan ini adalah SCP secara inheren mentolerir pandangan heterogen tentang node yang ada. Oleh karena itu, node dapat bergabung dan keluar secara sepihak tanpa memerlukan a Protokol “lihat perubahan” untuk mengoordinasikan keanggotaan. 3.1 Perjanjian Federasi Bizantium Masalah perjanjian tradisional Bizantium terdiri dari a sistem tertutup dari N node, beberapa di antaranya rusak dan mungkin berperilaku sewenang-wenang. Node menerima nilai masukan dan pertukaran pesan untuk memutuskan nilai output di antara input. Protokol perjanjian Bizantium aman ketika tidak ada dua node yang berperilaku baik menghasilkan keputusan yang berbeda dan unik keputusan merupakan masukan yang valid (untuk beberapa definisi valid yang disepakatiSOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. sebelumnya). Sebuah protokol aktif jika menjamin hal itu setiap node yang jujur pada akhirnya menghasilkan keputusan. Biasanya, protokol mengasumsikan N = 3f + 1 untuk beberapa bilangan bulat f > 0, maka menjamin keamanan dan beberapa bentuk keaktifan selama paling banyak f node rusak. Pada tahap tertentu dalam hal ini protokol, node memberikan suara pada nilai yang diusulkan dan proposal menerima 2f + 1 suara, yang disebut kuorum suara, menjadi keputusannya. Dengan N = 3f + 1 node, dua kuorum mana pun ukuran 2f + 1 tumpang tindih setidaknya di f + 1 node; bahkan jika f dari ini node yang tumpang tindih salah, setidaknya kedua kuorum berbagi satu node yang tidak salah, mencegah keputusan yang kontradiktif. Namun, pendekatan ini hanya berhasil jika semua node menyetujuinya apa yang dimaksud dengan kuorum, yang tidak mungkin dilakukan di SCP di mana dua node bahkan mungkin tidak mengetahui keberadaan satu sama lain. Dengan SCP, setiap node v secara sepihak mendeklarasikan kumpulan node, disebut irisan kuorumnya, sehingga (a) v percaya bahwa jika semua anggota irisan setuju tentang keadaan sistem, lalu mereka benar, dan (b) v percaya bahwa setidaknya salah satu bagiannya akan tersedia untuk memberikan informasi yang tepat waktu tentang keadaan sistem. Kami menyebut sistem yang dihasilkan, terdiri node dan irisannya, Perjanjian Federasi Bizantium (FBA) sistem. Seperti yang akan kita lihat selanjutnya, sistem kuorum muncul dari irisan node. Secara informal, potongan node FBA mengungkapkan dengan siapa simpul memerlukan persetujuan. Misalnya, sebuah node mungkin memerlukan persetujuan dengan 4 organisasi tertentu, masing-masing menjalankan 3 node; untuk mengakomodasi downtime, ia mungkin mengatur irisannya menjadi semua set terdiri dari 2 node dari masing-masing organisasi. Jika ini “membutuhkan perjanjian dengan” relasi secara transitif menghubungkan dua node mana pun, kita mendapatkan kesepakatan global. Kalau tidak, kita bisa mendapatkan perbedaan, tetapi hanya antar organisasi yang keduanya tidak memerlukannya kesepakatan dengan yang lain. Mengingat topologi saat ini sistem keuangan, kami berhipotesis bahwa konvergensi yang meluas akan terus menghasilkan sejarah buku besar yang disebut orang “jaringan Stellar,” sama seperti kita berbicara tentang Internet. Kuorum muncul dari irisan sebagai berikut. Setiap node menentukan irisan kuorumnya di setiap pesan yang dikirimkannya. Biarkan S menjadi kumpulan node asal kumpulan pesan. SEBUAH node menganggap kumpulan pesan telah mencapai kuorum ambang batas ketika setiap anggota S memiliki irisan yang termasuk dalam S. Secara konstruksi, himpunan S, jika bulat, memenuhi persyaratan kesepakatan masing-masing anggotanya. Rekan yang salah mungkin mengiklankan potongan yang dibuat untuk mengubah apa node yang berperilaku baik mempertimbangkan kuorum. Demi analisis protokol, kami mendefinisikan kuorum di FBA sebagai tidak kosong kumpulan S node yang mencakup setidaknya satu irisan kuorum setiap anggota yang tidak salah. Abstraksi ini masuk akal, seperti kumpulan lainnya pesan yang dimaksudkan untuk mewakili kuorum dengan suara bulat sebenarnya demikian (walaupun berisi pesan dari node yang salah), dan tepatnya jika S hanya berisi node yang berperilaku baik. Di Pada bagian ini, kami juga berasumsi bahwa irisan node tidak berubah. Namun demikian, hasil kami ditransfer ke kasus yang berubah-ubah karena sistem di mana perubahan irisan tidak kalah amannya sistem irisan tetap di mana irisan simpul terdiri dari semua irisan yang pernah digunakan dalam kasus perubahan irisan (lihat Teorema 13 di [68]). Seperti yang dijelaskan di Bagian 4, keaktifan bergantung pada node yang berperilaku baik pada akhirnya menghapus node yang tidak dapat diandalkan dari irisan mereka. Karena node yang berbeda memiliki persyaratan perjanjian yang berbeda, FBA menghalangi definisi keselamatan secara global. Kami bilang node yang tidak rusak v1 dan v2 saling terkait ketika masing-masing kuorum v1 memotong setiap kuorum v2 di setidaknya satu simpul yang tidak rusak. Protokol FBA dapat memastikan kesepakatan hanya antara node yang saling terkait; karena SCP melakukannya, itu salahnya toleransi terhadap keselamatan optimal. Hipotesis Internet, yang mendasari desain Stellar, menyatakan bahwa node tersebut dipedulikan orang tentang akan terjalin. Kita mengatakan himpunan node I utuh jika I merupakan kuorum yang tidak salah secara seragam sehingga setiap dua anggota I saling terkait meskipun setiap node di luar I salah. Secara intuitif, maka, aku harus tetap kebal terhadap tindakan yang tidak utuh node. SCP menjamin keaktifan non-pemblokiran [93] dan keamanan ke set utuh, meskipun node itu sendiri tidak memerlukannya untuk mengetahui (dan mungkin tidak dapat mengetahui) himpunan mana yang utuh. Selanjutnya gabungan dua himpunan utuh yang berpotongan adalah satu set utuh. Oleh karena itu, himpunan utuh mendefinisikan partisi dari node berperilaku baik, di mana setiap partisi aman dan aktif (dalam kondisi tertentu), tetapi partisi yang berbeda mungkin menghasilkan output keputusan yang berbeda. 3.1.1 Pertimbangan Keamanan vs. Keaktifan di FBA Dengan pengecualian terbatas [64], sebagian besar protokol perjanjian Bizantium tertutup disesuaikan dengan titik keseimbangan di mana keamanan dan keaktifan memiliki toleransi kesalahan yang sama. Di FBA, itu berarti konfigurasi di mana, terlepas dari kegagalannya, semuanya set yang saling terkait juga utuh. Mengingat FBA yang menentukan kuorum dengan cara yang terdesentralisasi, kecil kemungkinannya bahwa pilihan masing-masing kelompok akan menghasilkan keseimbangan ini. Apalagi di setidaknya di Stellar, keseimbangan tidak diinginkan: konsekuensinya kegagalan keamanan (yaitu uang digital yang dibelanjakan ganda). jauh lebih buruk dibandingkan dengan kegagalan keaktifan (yaitu penundaan dalam pembayaran yang memakan waktu beberapa hari sebelum Stellar). Orang-orang oleh karena itu sebaiknya dan lakukan pemilihan kuorum yang besar sedemikian rupa simpul-simpulnya cenderung tetap saling terkait dibandingkan utuh. Lebih jauh lagi, lebih mudah untuk pulih kegagalan keaktifan yang khas dalam sistem FBA dibandingkan sistem tertutup tradisional. Dalam sistem tertutup, semua pesan harus ada ditafsirkan sehubungan dengan kumpulan kuorum yang sama. Oleh karena itu, menambah dan menghapus node untuk pulih dari kegagalan diperlukan mencapai konsensus mengenai peristiwa konfigurasi ulang, yang sulit dilakukan ketika konsensus tidak lagi berlaku. Sebaliknya, dengan FBA, node mana pun dapat menyesuaikan irisan kuorumnya secara sepihak waktu. Menanggapi pemadaman pada sistem yang penting organisasi, administrator node dapat menyesuaikan irisannya mengatasi masalah, seperti mengoordinasikan tanggapan terhadap bencana BGP [63] (meskipun tanpa kendala perutean melalui tautan jaringan fisik).
Pembayaran global yang cepat dan aman dengan Stellar SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada 3.1.2 Teorema kaskade SCP mengikuti templat model putaran dasar [42]; node maju melalui serangkaian surat suara bernomor, masing-masing mencoba tiga tugas: (1) mengidentifikasi nilai “aman” yang tidak bertentangan dengan keputusan apa pun dalam pemungutan suara sebelumnya (sering disebut menyiapkan surat suara), (2) menyepakati nilai aman, dan (3) mendeteksi bahwa kesepakatan berhasil. Namun, FBA terbuka keanggotaan menghalangi beberapa teknik umum, sehingga berhasil tidak mungkin untuk "memindahkan" protokol tertutup tradisional ke FBA model hanya dengan mengubah definisi kuorum. Salah satu teknik yang digunakan oleh banyak protokol adalah rotasi melalui node pemimpin dengan cara round-robin setelah batas waktu habis. Dalam sistem tertutup, pemilihan pemimpin dilakukan secara round-robin yang pada akhirnya seorang pemimpin yang jujur dan unik akhirnya mengoordinasikan kesepakatan mengenai satu nilai. Sayangnya, sistem round-robin tidak dapat bekerja di sistem FBA dengan keanggotaan yang tidak diketahui. Teknik umum lainnya yang gagal dengan FBA adalah mengasumsikan kuorum tertentu dapat meyakinkan semua node. Misalnya, jika semua orang mengakui node 2f + 1 mana pun sebagai kuorum, maka Tanda tangan 2f + 1 cukup untuk membuktikan status protokol ke semua node. Demikian pula, jika sebuah node menerima kuorum pesan yang identik melalui siaran yang andal [24], node dapat berasumsi bahwa semua node yang tidak salah juga akan memenuhi kuorum. Di FBA, sebaliknya, a kuorum tidak berarti apa-apa bagi node di luar kuorum. Terakhir, sistem non-federasi sering kali menggunakan sistem “terbelakang” alasan tentang keamanan: jika f + 1 node rusak, semua aman jaminan hilang. Oleh karena itu, jika node v mendengar f + 1 node semuanya nyatakan beberapa fakta F, v dapat berasumsi setidaknya ada satu fakta yang memberitahukan kebenaran (dan karenanya F benar) tanpa kehilangan keamanan. Seperti itu penalaran gagal di FBA karena keselamatan adalah milik pasangan node, sehingga node yang kehilangan keamanannya terhadap beberapa peer dapat melakukannya selalu kehilangan keamanan ke lebih banyak node dengan mengasumsikan fakta buruk. Namun, FBA dapat berpikir mundur tentang keaktifan. Definisikan himpunan pemblokiran v sebagai himpunan node yang berpotongan setiap potongan v. Jika himpunan pemblokiran v B benar-benar rusak, B dapat menolak simpul v kuorum dan membuatnya kehilangan keaktifan. Oleh karena itu, jika B dengan suara bulat menyatakan fakta F, maka v mengetahui bahwa salah satu F adalah benar atau v tidak utuh. Namun, v masih perlu melihat selengkapnya kuorum untuk mengetahui bahwa node yang saling terkait tidak akan bertentangan dengan F, yang mengarah ke putaran terakhir komunikasi di SCP dan protokol FBA lainnya [47] yang tidak diperlukan secara analog protokol keanggotaan tertutup. Hasilnya adalah yang kita miliki tiga kemungkinan tingkat keyakinan terhadap fakta-fakta potensial: tidak dapat ditentukan, aman untuk diasumsikan di antara simpul-simpul yang utuh (yang akan kita lakukan istilah fakta yang diterima), dan aman untuk diasumsikan di antara saling terkait node (yang kita sebut fakta yang dikonfirmasi). Node v dapat secara efisien menentukan apakah suatu himpunan B melakukan vblocking dengan memeriksa apakah B memotong semua irisannya. Menariknya, jika node selalu mengumumkan pernyataan mereka menerima dan kuorum penuh menerima suatu pernyataan, hal ini memicu proses berjenjang dimana pernyataan disebarkan ke seluruh set utuh. Kami menyebut fakta kunci yang mendasari penyebaran ini teorema cascade, yang menyatakan sebagai berikut: Jika saya adalah an himpunan utuh, Q adalah kuorum anggota I, dan S adalah kuorum mana pun superset dari Q, maka S ⊇I atau ada anggota v ∈I sehingga v < S dan I ∩S merupakan pemblokiran v. Secara intuitif, apakah ini tidak demikian, komplemen dari S akan memenuhi kuorum yang memotong I tetapi tidak Q, melanggar kuorum persimpangan. Perhatikan bahwa jika kita memulai dengan S = Q dan berulang kali memperluas S menjadi menyertakan semua node yang diblokirnya, kami memperoleh efek berjenjang hingga, akhirnya, S mencakup seluruh I. 3.2 Deskripsi protokol SCP adalah protokol konsensus yang sebagian tersinkronisasi [42] yang terdiri dari serangkaian upaya untuk mencapai konsensus yang disebut surat suara. Surat suara menerapkan batas waktu yang durasinya semakin lama. SEBUAH protokol sinkronisasi surat suara memastikan bahwa node tetap aktif surat suara yang sama untuk jangka waktu yang bertambah hingga pemungutan suara secara efektif sinkron. Penghentian tidak dijamin sampai surat suara sinkron, tetapi dua surat suara sinkron yang dilakukan oleh anggota yang salah dari irisan node yang berperilaku baik tidak ikut campur saja sudah cukup untuk menghentikan SCP. Protokol pemungutan suara menentukan tindakan yang diambil pada masing-masing tindakan pemungutan suara. Pemungutan suara dimulai dengan fase persiapan, di mana node cobalah untuk menentukan nilai yang akan diusulkan yang tidak bertentangan keputusan apa pun sebelumnya. Kemudian, dalam fase penerapan, node mencoba untuk membuat keputusan tentang nilai yang disiapkan. Pemungutan suara menggunakan sub-protokol perjanjian yang disebut pemungutan suara gabungan, in node mana yang memberikan suara pada pernyataan abstrak yang pada akhirnya mungkin terkonfirmasi atau terhenti. Beberapa pernyataan mungkin dianggap bertentangan, dan aman jaminan pemungutan suara gabungan adalah tidak ada dua anggota dari suatu himpunan yang saling terkait menegaskan pernyataan-pernyataan yang kontradiktif. Konfirmasi suatu pernyataan tidak dijamin kecuali utuh himpunan yang semua anggotanya memberikan suara yang sama. Namun, jika a anggota himpunan utuh mengkonfirmasi suatu pernyataan, terfederasi pemungutan suara menjamin bahwa semua anggota kelompok utuh pada akhirnya mengkonfirmasi pernyataan itu. Oleh karena itu, mengambil langkah-langkah yang tidak dapat diubah sebagai tanggapan terhadap pernyataan yang mengkonfirmasikan mempertahankan keaktifan node utuh. Node awalnya mengusulkan nilai yang diperoleh dari nominasi protokol yang meningkatkan peluang semua anggota utuh himpunan mengusulkan nilai yang sama, dan akhirnya konvergen (meskipun tidak ada cara untuk menentukan konvergensi selesai). Nominasi menggabungkan pemungutan suara gabungan dengan pemilihan pemimpin. Karena round-robin tidak mungkin dilakukan di FBA, nominasi digunakan skema pemilihan pemimpin yang probabilistik. Teorema kaskade memainkan peran penting dalam pemungutan suara sinkronisasi dan menghindari negara-negara yang diblokir dari mana penghentian tidak mungkin lagi dilakukan. 3.2.1 Pemungutan suara Node SCP melanjutkan melalui serangkaian pemungutan suara bernomor, menggunakan pemungutan suara gabungan untuk menyetujui pernyataan tentang hal tersebut nilai-nilai ditentukan atau tidak ditentukan dalam surat suara yang mana. Jika asinkron atau perilaku salah menghalangi tercapainya keputusan dalam pemungutan suara n, waktu node habis dan coba lagi dalam pemungutan suara n + 1.
SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. Ingat, pemungutan suara gabungan mungkin tidak akan berakhir. Oleh karena itu, beberapa pernyataan tentang surat suara bisa macet secara permanen keadaan tak tentu di mana node tidak pernah dapat menentukan apakah mereka masih dalam proses atau macet. Karena node tidak bisa dikesampingkan kemungkinan pernyataan yang tidak pasti kemudian terbukti benar, mereka tidak boleh melakukan pemungutan suara gabungan untuk pernyataan baru bertentangan dengan yang tidak pasti. Di setiap n pemungutan suara, node menggunakan pemungutan suara gabungan pada dua jenis pernyataan: • siapkan ⟨n,x⟩– menyatakan tidak ada nilai selain x telah atau akan pernah diputuskan dalam pemungutan suara apa pun ≤n. • melakukan ⟨n,x⟩– menyatakan x ditentukan dalam pemungutan suara n. Yang penting, perhatikan bahwa persiapkan ⟨n,x⟩kontradiksi dilakukan ⟨n′,x ′⟩ketika n ≥n′ dan x , x ′. Sebuah node memulai pemungutan suara n dengan mencoba pemungutan suara gabungan pada a persiapan pernyataan ⟨n,x⟩. Jika ada pernyataan persiapan sebelumnya berhasil dikonfirmasi melalui pemungutan suara gabungan, itu node memilih x dari persiapan yang dikonfirmasi dari pemungutan suara tertinggi. Jika tidak, node akan menetapkan x ke output dari protokol nominasi dijelaskan dalam sub-bagian berikutnya. Jika dan hanya jika sebuah node berhasil mengonfirmasi persiapan ⟨n,x⟩ dalam pemungutan suara n, ia mencoba melakukan pemungutan suara gabungan pada komit ⟨n,x⟩. Jika jika berhasil, berarti SCP telah memutuskan, sehingga node mengeluarkan output nilai dari pernyataan komit yang dikonfirmasi. Pertimbangkan himpunan S yang saling terkait. Karena paling banyak satu nilai dapat dipastikan disiapkan oleh anggota S dalam pemungutan suara tertentu, tidak ada dua nilai berbeda yang dapat dikonfirmasi dilakukan olehnya anggota S dalam pemungutan suara tertentu. Apalagi jika melakukan ⟨n,x⟩ sudah dikonfirmasi, lalu siapkan ⟨n,x⟩telah dikonfirmasi juga; sejak itu siapkan ⟨n,x⟩kontradiksi dengan komitmen sebelumnya untuk nilai yang berbeda, dengan jaminan perjanjian pemungutan suara gabungan kami mendapatkan bahwa tidak ada nilai berbeda yang dapat diputuskan sebelumnya pemungutan suara oleh anggota S. Dengan memasukkan nomor suara, kami oleh karena itu pastikan SCP aman. Untuk keaktifan, pertimbangkan himpunan I yang utuh dan cukup panjang pemungutan suara sinkron n. Jika node yang rusak muncul di irisan node yang berperilaku baik tidak ikut campur dalam n, lalu melalui pemungutan suara n + 1 semua anggota I telah mengkonfirmasi set P pernyataan persiapan yang sama. Jika P = ∅dan surat suara n cukup panjang, maka protokol nominasi akan berkumpul pada beberapa nilai x. Jika tidak, misalkan x adalah nilai dari persiapan dengan pemungutan suara tertinggi di P. Apa pun yang terjadi, saya akan mencoba melakukan federasi secara seragam memberikan suara pada persiapan ⟨n + 1,x⟩pada pemungutan suara berikutnya. Oleh karena itu, jika n + 1 juga sinkron, keputusan untuk x pasti akan mengikuti. 3.2.2 Nominasi Nominasi memerlukan pemungutan suara gabungan atas pernyataan: • mencalonkan x – menyatakan x adalah calon pengambil keputusan yang sah. Node dapat memilih untuk mencalonkan beberapa nilai—berbeda pernyataan yang dicalonkan tidak bertentangan. Namun, sekali sebuah node mengkonfirmasi pernyataan pencalonan apa pun, maka node tersebut berhenti memberikan suaranya mencalonkan nilai-nilai baru. Pemungutan suara gabungan masih memungkinkan sebuah node untuk melakukan hal tersebut mengkonfirmasi pernyataan pencalonan baru yang tidak dipilihnya, yang mana memilih-atau-menerima a dari kuorum menerima a dari kuorum a sah menerima dari set pemblokiran tidak berkomitmen memilih a diterima a dikonfirmasi a memilih ¬a Gambar 1. Tahapan pemungutan suara gabungan memungkinkan anggota dari suatu himpunan utuh untuk mengonfirmasi satu sama lain nilai-nilai yang dicalonkan sambil tetap menahan suara baru. Hasil nominasi yang (berkembang) adalah kombinasi deterministik dari semua nilai dalam pernyataan nominasi yang dikonfirmasi. Jika x mewakili satu set transaksi, node dapat mengambil gabungan himpunan, himpunan terbesar, atau himpunan dengan hash tertinggi, jadi selama semua node melakukan hal yang sama. Karena node menahan yang baru suara setelah mengkonfirmasi satu pernyataan nominasi, set pernyataan yang dikonfirmasi hanya dapat berisi banyak nilai. Fakta bahwa pernyataan yang dikonfirmasi dapat dipercaya menyebar himpunan utuh berarti simpul-simpul utuh pada akhirnya bertemu di kumpulan nilai nominasi yang sama dan karenanya hasil nominasi, meskipun pada titik yang tidak diketahui secara sewenang-wenang terlambat dalam protokol. Node menggunakan pemilihan pemimpin gabungan untuk mengurangi sejumlah nilai berbeda dalam pernyataan nominasi. Hanya saja seorang pemimpin yang belum memberikan suara untuk pernyataan pencalonan dapat menggunakan tanda x baru. Node lain menunggu kabar para pemimpin dan cukup menyalin suara pencalonan pemimpin mereka (yang sah). Untuk mengakomodasi kegagalan, kelompok pemimpin terus bertambah batas waktu terjadi, meskipun dalam praktiknya hanya beberapa node yang memperkenalkan nilai x baru. 3.2.3 Pemungutan suara gabungan Pemungutan suara gabungan menggunakan protokol tiga fase yang ditunjukkan pada Gambar 1. Node mencoba menyepakati pernyataan abstrak terlebih dahulu pemungutan suara, kemudian menerima, dan akhirnya mengkonfirmasi pernyataan. Sebuah node v dapat memilih pernyataan valid a yang tidak valid bertentangan dengan yang lainsuara beredar dan pernyataan yang diterima. Hal ini dilakukan dengan menyiarkan pesan pemungutan suara yang ditandatangani. v kemudian menerima a jika a konsisten dengan pernyataan lain yang diterima dan salah satu dari (kasus 1)v adalah anggota kuorum di mana setiap node memilih a atau menerima a, atau (kasus 2) meskipun v tidak memilih a, set pemblokiran v menerima a. Dalam kasus 2, v mungkin sebelumnya telah memberikan suara yang bertentangan dengan a, yang sekarang telah telah ditolak. v diperbolehkan untuk melupakan suara yang ditolak dan berpura-pura tidak pernah membuangnya karena jika masih utuh, ia tahu suara yang dibatalkan tidak dapat memenuhi kuorum melalui kasus 1. v menyiarkan bahwa ia menerima a, lalu mengonfirmasi a jika sudah masuk kuorum yang dengan suara bulat menerima a. Gambar 2 menunjukkan efek himpunan pemblokiran v dan teorema kaskade selama pemungutan suara gabungan. Dua simpul yang saling terkait tidak dapat mengkonfirmasi pernyataan yang bertentangan, karena dua kuorum yang disyaratkan harus berbagi aPembayaran global yang cepat dan aman dengan Stellar SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada 3 4 2 1 5 7
Pilih X
Pilih Y (a) 3 4 2 1 5 7 6 Pilih X Pilih X Pilih X Pilih Y Pilih X Pilih Y Pilih Y (b) 3 4 2 1 5 7 6 Terima X Pilih X Terima X Pilih Y Terima X Pilih Y Pilih Y (c) 3 4 2 1 5 7 6 Terima X Terima X Terima X Pilih Y Terima X Terima X Pilih Y (d) 3 4 2 1 5 7 6 Terima X Pilih X Terima X Terima X Terima X Terima X Terima X (e) Gambar 2. Efek kaskade dalam pemungutan suara gabungan. Setiap node memiliki satu irisan kuorum yang ditunjukkan oleh panah ke anggota irisan tersebut. (a) Pernyataan yang bertentangan X dan Y diperkenalkan. (b) Node memilih pernyataan yang valid. (c) Node 1 menerima X setelah kuorumnya {1, 2, 3, 4} dengan suara bulat memilih X. (d) Node 1, 2, 3, dan 4 semuanya menerima X; set {1} adalah 5 pemblokiran, jadi node 5 menerima X, mengesampingkan suara sebelumnya untuk Y. (e) Himpunan {5} adalah pemblokiran 6 dan 7, jadi 6 dan 7 keduanya menerima X. node yang tidak salah yang tidak dapat menerima pernyataan yang kontradiktif. Konfirmasi suatu pernyataan tidak dijamin: in jika terjadi suara terbelah, kedua pernyataan tersebut dapat bersifat permanen terjebak menunggu kuorum dalam tahap pemungutan suara. Namun jika sebuah simpul dalam himpunan utuh Saya mengonfirmasi pernyataan, kaskade teorema dan menerima kasus 2 memastikan bahwa semua I pada akhirnya akan terjadi mengkonfirmasi pernyataan itu. 3.2.4 Sinkronisasi surat suara Jika node tidak dapat mengkonfirmasi pernyataan komit untuk pemungutan suara saat ini, mereka menyerah setelah batas waktu habis. Batas waktunya habis lebih lama pada setiap surat suara untuk menyesuaikan dengan batasan yang sewenang-wenang pada penundaan jaringan. Namun, waktu tunggu saja tidak cukup untuk menyinkronkan surat suara dari node yang tidak dimulai pada waktu yang sama atau menjadi tidak sinkron karena alasan lain. Untuk mencapai sinkronisasi, node memulai timer hanya ketika mereka menjadi bagian dari a kuorum yang semuanya ada pada pemungutan suara saat ini (atau nanti) n. Ini memperlambat node yang dimulai lebih awal dan memastikan bahwa tidak anggota himpunan utuh berada terlalu jauh di depan grup. Terlebih lagi, jika sebuah node v menyadari adanya pemblokiran v di kemudian hari surat suara, ia langsung melompat ke surat suara terendah seperti ini tidak lagi terjadi, terlepas dari pengatur waktunya. Kaskade teorema kemudian memastikan bahwa semua orang yang tersesat dapat mengejar ketinggalan. Hasilnya adalah bahwa surat suara secara kasar disinkronkan secara utuh diatur setelah sistem menjadi sinkron. 3.2.5 Pemilihan pemimpin gabungan Pemilihan pemimpin memungkinkan setiap node untuk memilih pemimpin sedemikian rupa cara node umumnya hanya memilih satu atau sejumlah kecil pemimpin. Untuk mengakomodasi kegagalan pemimpin, pemilihan pemimpin berlangsung melalui putaran. Jika pemimpin putaran saat ini tampak tidak memenuhi tanggung jawabnya, kemudian setelah a node dengan periode batas waktu tertentu melanjutkan ke putaran berikutnya memperluas kelompok pemimpin yang mereka ikuti. Setiap putaran menggunakan dua fungsi kriptografi unik hash, H0 dan H1, yang menghasilkan bilangan bulat dalam rentang [0,hmax). Misalnya, Stellar menggunakan Hi(m) = SHA256(i∥b∥r ∥m), di mana b adalah keseluruhan instance SCP (nomor blok atau buku besar), r adalah nomor putaran pemilihan pemimpin, dan hmax = 2256. Dalam putaran, kami mendefinisikan prioritas node v sebagai: prioritas(v) = H1(v) Satu strawman akan dipilih oleh setiap node sebagai pemimpin nodev dengan prioritas tertinggi (v). Pendekatan ini berhasil baik dengan potongan kuorum yang hampir sama, tetapi tidak tepat menangkap pentingnya node dalam konfigurasi yang tidak seimbang. Misalnya, jika Eropa dan Tiongkok masing-masing berkontribusi 3 node ke setiap kuorum, tetapi Tiongkok menjalankan 1.000 node dan Eropa 4, maka Tiongkok akan memiliki node dengan prioritas tertinggi 99,6% waktu itu. Oleh karena itu kami memperkenalkan pengertian berat irisan, dimana bobot(u,v) ∈[0, 1] adalah pecahan dari irisan kuorum simpul u berisi simpul v. Ketika simpul u memilih pemimpin baru, simpul itu hanya mempertimbangkan tetangga, yang didefinisikan sebagai berikut: tetangga(u) = { v | H0(v) < hmaks · berat(u,v) } Sebuah nodeu kemudian dimulai dengan sekumpulan pemimpin yang kosong, dan pada masing-masing pemimpin round menambahkan node v di tetangga (u) dengan yang tertinggi prioritas(v). Jika himpunan tetangga kosong di setiap putaran, u malah menambahkan nodev dengan nilai terendah H0(v)/berat(u,v).
Verifikasi formal SCP
Untuk menghilangkan kesalahan desain, kami secara resmi memverifikasi keamanan SCP dan sifat keaktifan (lihat [65]). Secara khusus, kami memverifikasi bahwa titik-titik yang berjalin tidak pernah berselisih dan, dalam kondisi yang dibahas di bawah, setiap anggota himpunan utuh pada akhirnya memutuskan. Menariknya, verifikasi mengungkapkan bahwa kondisi di mana SCP menjamin keaktifan sangat halus, dan lebih kuat dari perkiraan awal [68]: seperti dibahas di bawah, node jahat yang memanipulasi waktu tanpa melakukan sebaliknya menyimpang dari protokol mungkin perlu diusir secara manual dari irisan kuorum.
SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. Untuk memastikan bahwa properti terbukti tahan di semua kemungkinan Konfigurasi dan eksekusi FBA, kami anggap sewenang-wenang jumlah node dengan konfigurasi lokal sewenang-wenang. Ini mencakup skenario dengan rangkaian utuh yang terputus-putus, serta kemungkinan eksekusi yang sangat lama. Kekurangannya adalah kita menghadapi masalah yang menantang dalam memverifikasi parameterisasi sistem keadaan tak terbatas. Agar verifikasi tetap dapat dilakukan, kami memodelkan SCP dalam logika orde pertama (FOL) menggunakan Ivy [69] dan metodologi [82]. Proses verifikasi terdiri dari penyediaan dugaan induktif secara manual yang kemudian diperiksa secara otomatis ivy. Model FOL dari SCP mengabstraksi beberapa aspek Sistem FBA yang sulit ditangani di FOL (mis., teorema cascade diambil sebagai aksioma), jadi kami memverifikasi kesehatan abstraksi menggunakan Isabelle/HOL [75]. Setelah mengungkapkan masalah verifikasi di FOL, kami memverifikasi keamanan dengan menyediakan invarian induktif. Yang induktif invarian terdiri dari selusin dugaan satu baris untuk kira-kira 150 baris spesifikasi protokol. Kami kemudian menentukan properti keaktifan SCP dalam Logika Temporal Linier Ivy dan menggunakan keaktifan terhadap pengurangan keamanan [80, 81] untuk mengurangi keaktifan masalah verifikasi ke masalah menemukan induktif invarian. Meskipun keamanan SCP relatif mudah Buktikan, argumen keaktifan SCP jauh lebih rumit dan rumit terdiri dari sekitar 150 invarian garis tunggal. Membuktikan keaktifan memerlukan formalisasi yang tepat asumsi di mana SCP memastikan penghentian. Kami awalnya mengira set utuh akan selalu saya hentikan jika semuanya anggota menghapus node yang salah dari irisan mereka [68]. Namun, hal ini ternyata belum cukup: seorang yang berperilaku baik (tetapi tidak utuh) simpul dalam kuorum anggota I bisa, berdasarkan pengaruh node yang salah, cegah penghentian dengan menyelesaikan kuorum tepat sebelum berakhirnya pemungutan suara, sehingga menyebabkan anggota I untuk memilih nilai x yang berbeda pada pemungutan suara berikutnya. Oleh karena itu, kita juga harus berasumsi bahwa, secara informal, setiap node dalam kuorum anggota I pada akhirnya juga menjadi tepat waktu atau tidak mengirim pesan sama sekali untuk jangka waktu yang cukup. Dalam praktiknya, ini berarti anggota I boleh perlu menyesuaikan irisannya hingga kondisinya bertahan. Ini masalah ini tidak melekat pada sistem FBA: Losa dkk. [47] hadir sebuah protokol yang keberlangsungannya bergantung pada pihak yang lebih lemah asumsi hanya sinkronisasi dan pemilihan pemimpin pada akhirnya, tanpa perlu menghapus node yang salah dari irisan.
Jaringan pembayaran
Bagian ini menjelaskan jaringan pembayaran Stellar, diimplementasikan sebagai mesin negara yang direplikasi [88] di atas SCP. 5.1 Model buku besar Buku besar Stellar dirancang berdasarkan abstraksi akun (dalam kontras dengan keluaran transaksi tak terpakai yang lebih berpusat pada koin atau UTXO model Bitcoin). Isi buku besar terdiri dari a kumpulan entri buku besar dari empat jenis berbeda: akun, garis kepercayaan, penawaran, dan data akun. Akun adalah prinsipal yang memiliki dan menerbitkan aset. Masing-masing akun diberi nama dengan kunci publik. Secara default, kunci pribadi yang sesuai dapat menandatangani transaksi untuk akun tersebut. Namun, akun dapat dikonfigurasi ulang untuk menambahkan penanda tangan lain dan membatalkan otorisasi kunci yang memberi nama akun tersebut, dengan a Opsi "multisig" yang memerlukan banyak penandatangan. Setiap akun juga berisi: nomor urut (termasuk dalam transaksi untuk mencegah pemutaran ulang), beberapa tanda, dan keseimbangan dalam “asli” cryptocurrency yang telah ditambang sebelumnya disebut XLM, dimaksudkan untuk melakukan mitigasi beberapa serangan penolakan layanan dan memfasilitasi pembuatan pasar sebagai mata uang netral. Trustlines melacak kepemilikan aset yang diterbitkan, yaitu diberi nama oleh pasangan yang terdiri dari akun penerbit dan short kode aset (misalnya, “USD” atau “EUR”). Setiap garis kepercayaan menentukan akun, aset, saldo akun dalam aset itu, a batas di mana saldo tidak dapat naik, dan beberapa bendera. Sebuah akun harus secara eksplisit menyetujui untuk memegang aset menciptakan garis kepercayaan, mencegah pelaku spam membebani akun dengan aset yang tidak diinginkan. Peraturan kenali pelanggan Anda (KYC) mengharuskan banyak lembaga keuangan mengetahui simpanan siapa yang mereka simpan, misalnya dengan memeriksa foto ID. Untuk mematuhinya, emiten dapat mengatur tanda auth_reqired opsional pada akun mereka, yang membatasi kepemilikan aset yang mereka keluarkan ke akun resmi. Untuk memberikan otorisasi tersebut, penerbit menetapkan otorisasi menandai garis kepercayaan pelanggan. Penawaran sesuai dengan kesediaan akun untuk berdagang ke sejumlah tertentu suatu aset tertentu untuk aset lain pada waktu tertentu harga di buku pesanan; mereka secara otomatis dicocokkan dan terisi ketika harga beli/jual bersilangan. Terakhir, data akun terdiri dari akun, kunci, nilai tiga kali lipat, yang memungkinkan pemegang akun untuk mempublikasikan nilai metadata kecil. Untuk mencegah spam ledger, ada minimal saldo XLM, disebut cadangan. Cadangan akun meningkat setiap kali entri buku besar terkait dan berkurang ketika entri buku besar menghilang (misalnya, ketika pesanan dipenuhi atau dibatalkan, atau ketika a garis kepercayaan dihapus). Saat ini cadangan tumbuh sebesar 0,5 XLM (∼$0,03) per entri buku besar. Terlepas dari cadangannya, itu benar mungkin untuk mendapatkan kembali seluruh nilai akun dengan menghapus dengan operasi AccountMerge. Header buku besar, yang ditunjukkan pada Gambar 3, menyimpan atribut global: nomor buku besar, parameter seperti saldo cadangan per entri buku besar, hash dari header buku besar sebelumnya (sebenarnya beberapa hashes membentuk daftar yang dilewati), keluaran SCP termasuk hash transaksi baru yang diterapkan di buku besar ini, hash dari hasil transaksi tersebut (misalnya, keberhasilan atau kegagalan untuk masing-masing), dan cuplikan hash dari semua entri buku besar. Karena snapshot hash mencakup semua isi buku besar, validators tidak perlu menyimpan riwayat untuk memvalidasi transaksi. Namun, untuk mencapai ratusan juta diantisipasi akun, kami tidak dapat hash semua tabel entri buku besar pada setiap tabel buku besar ditutup. Selain itu, tidak praktis untuk mentransfer buku besarPembayaran global yang cepat dan aman dengan Stellar SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada buku besar # = 4 H(sebelumnya hdr) keluaran SCP H∗(hasil) H∗(potret) ... tajuk buku besar # = 5 H(sebelumnya hdr) keluaran SCP H∗(hasil) H∗(potret) ... tajuk . . . Gambar 3. Isi buku besar. H adalah SHA-256, sedangkan H ∗ mewakili penerapan hierarki atau rekursif dari keluaran H. SCP juga tergantung header sebelumnya hash. Buat Akun Membuat dan mendanai entri buku besar akun baru Penggabungan Akun Hapus entri buku besar akun Set Opsi Ubah tanda dan penandatangan akun Pembayaran Bayar sejumlah aset tertentu ke tujuan. menurut. Pembayaran Jalur Suka Pembayaran, tetapi bayar dalam aset berbeda (naik untuk membatasi); tentukan hingga 5 aset perantara Kelola Penawaran Membuat/menghapus/mengubah entri buku besar penawaran, -Penawaran Pasif dengan varian pasif untuk memungkinkan penyebaran nol KelolaData Buat/hapus/ubah akun. entri buku besar data Ubah Kepercayaan Buat/hapus/ubah garis kepercayaan Izinkan Kepercayaan Setel atau hapus tanda resmi pada trustline Urutan Benjolan Tingkatkan urutan. nomor di akun Gambar 4. Operasi buku besar utama sebesar itu setiap kali sebuah node terputus jaringan terlalu lama. Oleh karena itu, snapshot hash adalah dirancang untuk mengoptimalkan hashing dan rekonsiliasi negara. Secara khusus, snapshot mengelompokkan entri buku besar berdasarkan waktu modifikasi terakhir dalam satu set wadah berukuran eksponensial disebut ember. Kumpulan ember disebut ember list, dan memiliki kemiripan dengan pohon gabungan berstruktur log (Pohon LSM) [77]. Daftar keinginan tidak dibaca selama pemrosesan transaksi (lihat Bagian 5.4). Oleh karena itu, desain tertentu aspek pohon LSM bisa dilonggarkan. Khususnya, acak akses dengan kunci tidak diperlukan, dan keranjang hanya dibaca secara berurutan sebagai bagian dari penggabungan level. Hashing ember list dilakukan dengan hashing setiap keranjang saat digabungkan dan menghitung hash kumulatif baru dari keranjang hashes (kecil, indeks referensi tetap hashes) pada setiap penutupan buku besar. Rekonsiliasi daftar keinginan setelah pemutusan sambungan memerlukan pengunduhan hanya ember yang berbeda. 5.2 Model transaksi Suatu transaksi terdiri dari akun sumber, kriteria validitas, a memo, dan daftar satu atau lebih operasi. Gambar 4 mencantumkan operasi yang tersedia. Setiap operasi memiliki akun sumber, yang mana default terhadap keseluruhan transaksi. Sebuah transaksi harus ditandatangani dengan kunci yang sesuai dengan setiap akun sumber di sebuah operasi. Akun multisig memerlukan penandatanganan yang lebih tinggi bobot untuk beberapa operasi (seperti SetOptions) dan lebih rendah untuk yang lain (seperti AllowTrust). Transaksi bersifat atomik—jika ada operasi yang gagal, tidak ada satu pun yang gagal mereka mengeksekusi. Ini menyederhanakan kesepakatan multi-arah. Misalkan sebuah penerbit membuat aset untuk mewakili akta tanah, dan pengguna A ingin menukar sebidang tanah kecil ditambah $10.000 dengan a sebidang tanah yang lebih besar milik B. Kedua pengguna dapat sama-sama menandatangani satu transaksi yang berisi tiga operasi: dua tanah pembayaran dan pembayaran satu dolar. Kriteria validitas utama suatu transaksi adalah nomor urutnya, yang harus lebih besar satu daripada nomor urut transaksi entri buku besar akun sumber. Menjalankan transaksi yang valid (berhasil atau tidak) menambah nomor urut, mencegah pemutaran ulang. Nomor urut awal berisi buku besar nomor dalam bit tinggi untuk mencegah pemutaran ulang bahkan setelah penghapusan dan membuat ulang akun. Kriteria validitas lainnya adalah batasan opsional kapan suatu transaksi dapat dijalankan. Kembali ke tanah dan dolar swap di atas, jika A menandatangani transaksi sebelum B, A tidak boleh ingin B melakukan transaksi selama setahun sebelum mengajukan itu, sehingga dapat menetapkan batas waktu yang membatalkan transaksi setelah beberapa hari. Akun multisig juga dapat dikonfigurasi untuk memberi bobot penandatanganan pada pengungkapan gambar awal hash, yang, dikombinasikan dengan batas waktu, memungkinkan perdagangan lintas rantai atom [1]. Akun sumber transaksi membayar sedikit biaya di XLM, 10−5 XLM kecuali terjadi kemacetan. Di bawah kemacetan, itu biaya operasi ditentukan oleh lelang Belanda. Validator adalah tidak dikompensasi dengan biaya karena validator serupa ke Bitcoin node penuh, bukan penambang. Daripada menghancurkan XLM, biaya didaur ulang dan didistribusikan secara proporsional melalui pemungutan suara pemegang XLM yang ada, yang jika dipikir-pikir mungkin atau mungkin tidak sebanding dengan kerumitannya. 5.3 Nilai-nilai konsensus Untuk setiap buku besar, Stellar menggunakan SCP untuk menyetujui struktur data dengan tiga bidang: kumpulan transaksi hash (termasuk hash dari header buku besar sebelumnya), waktu tutup, and peningkatan. Ketika beberapa nilai dikonfirmasi dinominasikan, Stellar mengambil kumpulan transaksi dengan operasi terbanyak (memutus ikatan berdasarkan total biaya, maka transaksi ditetapkan hash), gabungan semuanya peningkatan, dan waktu penutupan tertinggi. Waktu dekat saja valid jika berada di antara waktu penutupan buku besar terakhir dan hadir, sehingga node tidak mencalonkan waktu yang tidak valid. Peningkatan menyesuaikan parameter global seperti saldo cadangan, biaya operasi minimum, dan versi protokol. Kapan digabungkan selama pencalonan, biaya yang lebih tinggi dan nomor versi protokol menggantikan biaya yang lebih rendah. Peningkatan ini berdampak pada tata kelola melalui ruang pertarungan pemungutan suara gabungan [34], tidak juga egaliter dan tidak terpusat. Setiap validator dikonfigurasi sebagai baik yang mengatur atau tidak mengatur (default), menurut apakah operatornya ingin berpartisipasi dalam tata kelola. Mengatur validators mempertimbangkan tiga jenis peningkatan: diinginkan, valid, dan tidak valid (apa pun yang validator tidak
SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. validator inti cakrawala FS DB DB menyerahkan klien klien validator lainnya Gambar 5. Arsitektur Stellar validator tahu bagaimana menerapkannya). Peningkatan yang diinginkan dikonfigurasikan ke pemicu pada waktu tertentu, dimaksudkan untuk dikoordinasikan antar operator. Node yang mengatur selalu memilih untuk mencalonkan yang diinginkan peningkatan, terima tetapi jangan memilih untuk mencalonkan peningkatan yang valid (yaitu, ikut serta dalam kuorum pemblokiran), dan jangan pernah memilih atau menerima peningkatan yang tidak valid. Gema validator yang tidak mengatur setiap suara yang mereka lihat untuk peningkatan yang valid, pada dasarnya mendelegasikan keputusan tentang peningkatan apa yang diinginkan bagi mereka yang memilih untuk peran tata kelola. 5.4 Implementasi Gambar 5 menunjukkan arsitektur validator Stellar. Sebuah dasmon disebut stellar-core (∼92k baris C++, tidak termasuk perpustakaan pihak ketiga) mengimplementasikan protokol SCP dan mesin negara yang direplikasi. Menghasilkan nilai untuk SCP memerlukan pengurangan sejumlah besar entri buku besar menjadi kriptografi kecil hashes. Sebaliknya, validasi dan eksekusi transaksi memerlukan pencarian status akun dan pencocokan pesanan di harga terbaik. Untuk menjalankan kedua fungsi secara efisien, inti yang luar biasa menyimpan dua representasi buku besar: representasi eksternal yang berisi daftar keinginan, disimpan sebagai file biner yang dapat diperbarui secara efisien dan diperbarui secara bertahap, dan representasi internal dalam database SQL (PostgreSQL untuk node produksi). Stellar-core membuat arsip riwayat hanya tulis yang berisi setiap kumpulan transaksi yang dikonfirmasi dan cuplikannya ember. Arsip ini memungkinkan node baru melakukan bootstrap sendiri saat bergabung dengan jaringan. Ini juga menyediakan catatan buku besar sejarah—perlu ada suatu tempat yang dapat dicari transaksi dari dua tahun lalu. Karena riwayat hanya bersifat tambahan dan jarang diakses, dapat disimpan di tempat yang murah seperti Amazon Glacier atau layanan apa pun yang mengizinkan seseorang untuk menyimpan dan mengambil file datar. Host validator biasanya tidak menghosting arsip mereka sendiri untuk menghindari dampak apa pun pada validasi kinerja dari melayani sejarah. Untuk menjaga agar inti bintang tetap sederhana, ini tidak dimaksudkan untuk digunakan langsung melalui aplikasi dan hanya memperlihatkan antarmuka yang sangat sempit untuk pengajuan transaksi baru. Untuk mendukung klien, sebagian besar validator menjalankan daemon bernama horizon (∼18k baris Go) yang menyediakan antarmuka HTTP untuk pengiriman dan pembelajaran transaksi. horizon memiliki akses hanya baca database SQL stellar-core, meminimalkan risiko horizon mendestabilisasi inti bintang. Fitur-fitur seperti pencarian jalur pembayaran diterapkan sepenuhnya dan dapat ditingkatkan secara sepihak tanpa berkoordinasi dengan validators lainnya. Beberapa daemon opsional pada lapisan yang lebih tinggi adalah klien yang harus dicakup, melengkapi ekosistem. Server jembatan memfasilitasi integrasi Stellar dengan sistem yang ada, misalnya memposting pemberitahuan semua pembayaran yang diterima oleh akun tertentu. SEBUAH server kepatuhan memberikan kaitan bagi lembaga keuangan untuk melakukannya menukar dan menyetujui informasi pengirim dan penerima tentang pembayaran, untuk mematuhi daftar sanksi. Akhirnya, server federasi mengimplementasikan penamaan yang dapat dibaca manusia sistem untuk akun. 6 Pengalaman penerapan Stellar tumbuh selama beberapa tahun menjadi keadaan yang moderat sejumlah operator node penuh yang cukup andal. Namun, Konfigurasi node sedemikian rupa sehingga hidup (meskipun tidak keselamatan) bergantung pada kami, Stellar Development Foundation (SDF); seandainya SDF tiba-tiba menghilang, operator node lainnya perlu campur tangan dan menghapus kami secara manual dari potongan kuorum agar jaringan dapat melanjutkan. Meskipun kami dan banyak pihak lain ingin mengurangi kepentingan sistemik SDF, tujuan ini semakin mendapat prioritas setelahnya peneliti [58] mengukur dan mempublikasikan sentralisasi jaringan tanpa membedakan risiko terhadap keselamatan dan keaktifan. Sejumlah operator bereaksi dengan penyesuaian konfigurasi aktif, terutama meningkatkan ukurannya kuorum dalam upaya melemahkan pentingnya SDF; ironisnya hal ini hanya meningkatkan risiko terhadap nyawa. Ada dua masalah yang memperburuk situasi. Pertama, yang populer alat pemantauan Stellar pihak ketiga [5] dilakukan secara sistematis melebih-lebihkan waktu aktif validator dengan tidak benar-benar memverifikasi inti bintang itu sedang berjalan; hal ini menyebabkan orang-orang ikut serta node yang tidak dapat diandalkan dalam irisan kuorumnya. Kedua, ada bug di dalamnya stellar-core berarti setelah validator dipindahkan ke buku besar berikutnya, itu tidak cukup membantu node yang tersisa menyelesaikan yang sebelumnyabuku besar kami jika terjadi pesan yang hilang. Akibatnya, jaringan mengalami downtime selama 67 menit dan diperlukan koordinasi manual oleh validator administrator untuk memulai kembali. Lebih buruk lagi, ketika mencoba memulai ulang jaringan, terjadi konfigurasi ulang yang terburu-buru secara bersamaan pada beberapa node dalam kesalahan konfigurasi kolektif yang memungkinkan beberapa node melakukannya menyimpang, membutuhkan penutupan manual dari node tersebut dan penyerahan kembali transaksi yang diterima selama divergensi. Untungnya, perbedaan ini dapat ditangkap dan diperbaiki cepat dan tidak mengandung transaksi yang bertentangan, tetapi risiko jaringan gagal mencapai kuorum persimpangan— perpecahan sambil terus menerima potensi konflik transaksi, hanya karena kesalahan konfigurasi—terjadi sangat konkrit dengan kejadian ini. Meninjau pengalaman-pengalaman ini menghasilkan dua kesimpulan utama dan tindakan perbaikan yang sesuai.Pembayaran global yang cepat dan aman dengan Stellar SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Kritis, 100% 51% 51% Tinggi, 67% 51% Sedang, 67% 51% Rendah, 67% 51% 51% ... ... ... 51% ... 51% Gambar 6. Hierarki kualitas validator. Node dengan kualitas terbaik memerlukan ambang batas tertinggi 100%, sedangkan kualitas yang lebih rendah dikonfigurasikan ke ambang batas 67%. Node dalam satu organisasi memerlukan mayoritas sederhana 51%. 6.1 Kompleksitas dan kerapuhan konfigurasi Stellar menyatakan irisan kuorum sebagai kumpulan kuorum bersarang yang terdiri dari n entri dan ambang batas k di mana setiap kumpulan k entri merupakan bagian kuorum. Masing-masing dari n entri adalah salah satunya kunci publik validator atau, secara rekursif, kumpulan kuorum lainnya. Meskipun fleksibel dan kompak, kami mewujudkan kuorum bertingkat set secara bersamaan memberi operator node terlalu banyak fleksibilitas dan terlalu sedikit panduan: mudah untuk menulis tidak aman (atau bahkan tidak masuk akal). Kriteria pengelompokan node menjadi set, untuk mengatur subset ke dalam hierarki, dan pemilihan ambang batas tidak cukup jelas dan berkontribusi terhadap kegagalan operasional. Tidak jelas apakah akan melakukannya memperlakukan "level" dalam hierarki kumpulan bersarang sebagai tingkat kepercayaan, atau suatu organisasi, atau keduanya; banyak konfigurasi di lapangan mencampuradukkan konsep-konsep ini, selain menentukan berbahaya atau ambang batas yang tidak berarti. Oleh karena itu kami menambahkan mekanisme konfigurasi yang lebih sederhana yang memisahkan dua aspek kumpulan kuorum bertingkat: pengelompokan node bersama-sama berdasarkan organisasi, dan memberi label pada setiap organisasi dengan klasifikasi kepercayaan sederhana (rendah, sedang, tinggi, atau kritis). Organisasi yang berada pada level tinggi dan di atasnya diharuskan untuk melakukan hal tersebut mempublikasikan arsip sejarah. Sistem baru ini mensintesis kumpulan kuorum bersarang di mana setiap organisasi direpresentasikan sebagai a Ambang batas 51% ditetapkan, dan organisasi dikelompokkan ke dalam beberapa set dengan ambang batas 67% atau 100% (tergantung kualitas kelompok). Setiap grup adalah satu entri di grup berikutnya (berkualitas lebih tinggi), seperti yang diilustrasikan pada Gambar 6. Model yang disederhanakan ini mengurangi kemungkinan kesalahan konfigurasi, baik dari segi struktur dari himpunan bersarang yang disintesis dan ambang batas yang dipilih setiap set. 6.2 Deteksi kesalahan konfigurasi secara proaktif Kedua, kami menyadari bahwa mendeteksi kesalahan konfigurasi kolektif dengan menunggu untuk mengamati dampak negatifnya sudah terlambat. Terutama sehubungan dengan kesalahan konfigurasi yang dapat menyimpang—a mode kegagalan yang lebih serius daripada penghentian—yang dibutuhkan jaringan agar dapat segera mendeteksi kesalahan konfigurasi sehingga operator dapat mengembalikannya sebelum terjadi divergensi. Untuk mengatasi kebutuhan ini, kami membangun mekanisme ke dalam perangkat lunak validator yang secara terus-menerus mengumpulkan status konfigurasi kolektif dari semua rekan dalam penutupan transitif node dan mendeteksi potensi divergensi—yaitu, disjoint kuorum—dalam konfigurasi kolektif itu. 6.2.1 Memeriksa persimpangan kuorum Meskipun mengumpulkan bagian kuorum itu mudah, menemukan kuorum yang terpisah di antara mereka adalah hal yang sulit [62]. Namun, kami mengadopsinya seperangkat heuristik algoritmik dan aturan eliminasi kasus diusulkan oleh Lachowski [62] yang memeriksa contoh umum dari masalah beberapa kali lipat lebih cepat dari biaya kasus terburuk. Secara praktis, jaringan saat ini penutupan transitif irisan kuorum berada di urutan 20–30 node dan, dengan optimasi Lachowski, biasanya memeriksa dalam hitungan detik pada satu CPU. Jika diperlukan untuk meningkatkan kinerja, kami dapat memparalelkan pencarian. 6.2.2 Memeriksa konfigurasi berisiko Mendeteksi bahwa jaringan mengakui kuorum yang terpisah adalah sebuah langkah ke arah yang benar, namun terlambat menandai bahaya untuk masalah kritis seperti itu. Idealnya, kami ingin operator node menerima peringatan saat konfigurasi kolektif jaringan hanya mendekati keadaan berisiko. Oleh karena itu, kami memperluas pemeriksaan kuorum persimpangan untuk mendeteksi suatu kondisi kita sebut kekritisan: ketika arus konfigurasi kolektif hanya berjarak satu kesalahan konfigurasi negara bagian yang mengakui kuorum yang terpisah. Untuk mendeteksi kekritisan, pemeriksa berulang kali mengganti konfigurasi masing-masing organisasi dengan simulasi kesalahan konfigurasi kasus terburuk menjalankan kembali pemeriksa persimpangan kuorum dalam pada hasilnya. Jika ada kesalahan konfigurasi kritis yang terjadi, tinggal selangkah lagi dari keadaan saat ini, perangkat lunak mengeluarkan peringatan dan melaporkan organisasi yang mempunyai risiko kesalahan konfigurasi. Perubahan ini memberikan komunitas operator dua lapisan pemberitahuan dan panduan untuk melindungi dari bentuk-bentuk terburuk kesalahan konfigurasi kolektif.
Evaluasi
Untuk memahami kesesuaian Stellar sebagai pembayaran global dan jaringan perdagangan, kami mengevaluasi keadaan jaringan publik dan menjalankan eksperimen terkontrol pada eksperimen pribadi jaringan. Kami fokus pada pertanyaan-pertanyaan berikut: • Seperti apa topologi jaringan produksinya? Berapa rata-rata pesan yang disiarkan, dan bagaimana SCP mengalami timeout? • Apakah latensi pembaruan konsensus dan buku besar tetap independen terhadap jumlah akun?SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. • Bagaimana latensi dipengaruhi oleh peningkatan (a) transaksi per detik (dan, akibatnya, transaksi per buku besar), dan (b) jumlah validator node? • Berapa biaya menjalankan sebuah node dalam kaitannya dengan CPU, memori, dan bandwidth jaringan? Jaringan pembayaran memiliki tingkat transaksi yang rendah dibandingkan ke jenis sistem terdistribusi lainnya. blockchains terkemuka, Bitcoin dan Ethereum, konfirmasi hingga 15 transaksi/detik, kurang dari Stellar. Selain itu, sistem ini memerlukan waktu beberapa menit untuk melakukannya satu jam untuk mengonfirmasi transaksi dengan aman, karena bukti kerja memerlukan menunggu beberapa blok untuk ditambang. Itu jaringan SWIFT non-blockchain rata-rata hanya melakukan 420 transaksi per detik pada hari puncaknya [14]. Oleh karena itu kami memilih untuk membandingkan pengukuran kami dengan target 5 detik interval buku besar, target yang lebih agresif. Hasil kami menunjukkan bahwa latensi masih berada di bawah batas ini beberapa pengoptimalan yang belum diterapkan masih dalam proses. 7.1 Jangkar Aset yang paling banyak diperdagangkan berdasarkan volume mencakup mata uang (misalnya, 3 USD jangkar, 2 CNY), jangkar Bitcoin, keamanan yang didukung real estat token [92], dan mata uang dalam aplikasi [8]. Jangkar yang berbeda memiliki kebijakan yang berbeda. Misalnya, satu jangkar USD, Stronghold, menetapkan auth_reqired dan memerlukan proses kenali pelanggan Anda (KYC) untuk setiap akun yang memilikinya aset. Lainnya, AnchorUSD, memungkinkan siapa pun menerima dan berdagang USD mereka (sehingga memungkinkan untuk mengirim $0,50 ke Meksiko dalam 5 detik dengan biaya $0,000001). Namun, JangkarUSD memang memerlukan KYC dan biaya untuk membeli atau menebus USD mereka dengan transfer kawat konvensional. Di Filipina, di mana peraturan bank lebih longgar untuk pembayaran masuk,coin.ph mendukung pencairan PHP di mesin ATM mana pun [36]. Selain token keamanan yang disebutkan di atas dan mata uang dalam aplikasi, terdapat berbagai token non-mata uang mulai dari obligasi komersial [22] dan kredit karbon [85, 96] dan lebih banyak lagi aset esoteris seperti token yang memberikan insentif kolaboratif penarikan kembali mobil [35]. 7.2 Jaringan publik Saat tulisan ini dibuat, terdapat 126 full node yang aktif, 66 di antaranya berpartisipasi dalam konsensus dengan menandatangani pesan suara. Gambar 7 (dihasilkan oleh [5]) memvisualisasikan jaringan, dengan garis di antaranya dua node jika salah satu muncul di bagian kuorum yang lain dan a garis biru gelap untuk menunjukkan ketergantungan dua arah. Di center adalah sekelompok 17 “tingkat satu validators” de facto yang dijalankan oleh SDF, SatoshiPay, LOBSTR, COINQVEST, dan Keybase. Empat bulan lalu, sebelum peristiwa Bagian 6, disana ada 15 node yang penting secara sistemik: 3 dari yang tampaknya organisasi tingkat satu dan beberapa lajang acak. Itu grafik juga terlihat kurang teratur. Oleh karena itu, nampaknya mekanisme konfigurasi baru dan/atau keputusan operator yang lebih baik untuk berkontribusi pada topologi jaringan yang lebih sehat. Tanpa sumber daya keuangan yang besar (dan pemegang saham terkait Gambar 7. Peta irisan kuorum kewajiban), akan sulit untuk merekrut 5 tingkat satu organisasi sejak awal. Hal ini menunjukkan kuorum irisan memainkan peran yang berguna dalam bootstraping jaringan: siapa pun bisa bergabung dengan tujuan menjadi pemain penting karena tidak ada penjaga gerbang untuk kesepakatan berpasangan. Saat ini ada lebih dari 3,3 juta akun di buku besar. Selesai periode 24 jam terakhir, Stellar rata-rata 4,5 transaksi dan 15,7 operasi per detik. Meninjau buku besar terbaru, sebagian besar transaksi tampaknya memiliki satu operasi, sementara setiap beberapa operasi di buku besar kita melihat transaksi yang berisi banyak operasi itu tampaknya berasal dari pembuat pasar yang mengelola penawaran. Itu waktu yang berarti untuk mencapai konsensus dan memperbarui buku besar 1061 ms dan 46 ms, masing-masing. Persentil ke-99 adalah 2252 mdtk dan 142 mdtk (yang pertama mencerminkan batas waktu 1 detik dalam pemilihan pemimpin nominasi). Catatan kinerja SCP adalah sebagian besar tidak bergantung pada transaksi per detik, sejak SCP menyetujui hash dari banyak transaksi yang sewenang-wenang. Kemacetan lebih besar kemungkinannya timbul dari pencalonan calon transaksi selama nominasi, pelaksanaan dan validasi transaksi, dan menggabungkan keranjang. Kami belum membutuhkannya untuk memparalelkan pemrosesan transaksi stellar-core pada beberapa inti CPU atau drive disk. Kami juga mengevaluasi jumlah pesan SCP yang disiarkan pada jaringan produksi. Dalam kasus normal dengan satu pemimpin terpilih untuk mencalonkan suatu nilai, kami mengharapkan tujuh logis pesan yang akan disiarkan: dua pesan untuk dipilih dan diterima seorang nomipernyataan nate, dua pesan untuk diterima dan dikonfirmasi pernyataan persiapan, dua pesan untuk diterima dan dikonfirmasi pernyataan komit, dan terakhir, pesan eksternalisasi (dikirim setelah melakukan buku besar baru ke disk untuk membantu orang yang tersesat mengejar ketinggalan). Implementasinya menggabungkan konfirmasi komit dan mengeksternalisasikan pesan sebagai optimasi, sebagaimana adanya aman untuk mengeksternalisasi suatu nilai setelah dikomit. Kami kemudian menganalisis metrik yang dikumpulkan pada Stellar validator produksi. Selesai selama 68 jam, 1,3 pesan/detik dikirimkan, rata-rata 6-7 pesan per buku besar. Kami mencatat bahwa totalnya
Pembayaran global yang cepat dan aman dengan Stellar SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Persentil Jumlah Batas Waktu Nominasi Pemungutan suara 75% 0 0 99% 1 0 Maks 4 1 Gambar 8. Batas waktu per buku besar selama 68 jam jumlah pesan yang disiarkan oleh validators lebih besar, sejak di selain pesan pemungutan suara gabungan, node juga menyiarkan transaksi apa pun yang mereka pelajari. Gambar 8 menunjukkan batas waktu yang dialami oleh suatu produksi validator selama jangka waktu 68 jam. Batas waktu nominasi adalah ukuran (tidak)efektifnya fungsi pemilihan pemimpin, sementara waktu tunggu pemungutan suara sangat bergantung pada jaringan dan potensi penundaan pesan. Batas waktunya konsisten dengan jumlah pesan yang dipancarkan: enam pesan di skenario kasus terbaik, dan setidaknya tujuh pesan jika putaran nominasi tambahan diperlukan. 7.3 Eksperimen terkontrol Kami menjalankan eksperimen terkontrol dalam wadah yang dikemas Instans Amazon EC2 c5d.9xlarge dengan RAM 72 GiB, NVMe SSD 900 GB, dan 36 vCPU. Setiap contoh ada di wilayah EC2 yang sama dan memiliki bandwidth tetap 10 Gbps. Kami menggunakan SQLite sebagai toko. (Stellar juga mendukung PostgreSQL, tapi itu memiliki tugas asinkron yang memasukkan kebisingan ke dalam pengukuran.) Stellar menyediakan kueri runtime bawaan, generateload, yang memungkinkan menghasilkan beban sintetis pada target tertentu transaksi/kurs kedua. Meskipun Stellar mendukung beragam fitur perdagangan, seperti buku pesanan dan jalur lintas aset pembayaran, kami fokus pada pembayaran sederhana. Mengonfirmasi transaksi terdiri dari beberapa langkah, jadi kami mencatat pengukuran untuk setiap hal berikut: • Nominasi: waktu dari nominasi hingga persiapan pertama • Pemungutan suara: waktu dari persiapan pertama hingga pengukuhan a pemungutan suara dilakukan • Pembaruan buku besar: saatnya menerapkan nilai konsensus • Jumlah transaksi: transaksi terkonfirmasi per buku besar Setiap eksperimen kami ditentukan oleh tiga parameter: jumlah entri akun dalam buku besar, jumlah beban (berupa pembayaran XLM) yang dikirimkan per detik, dan jumlah validators. Kami mengonfigurasi setiap validator untuk mengetahui tentang setiap validator lainnya (skenario terburuk untuk SCP), dengan potongan kuorum ditetapkan ke mayoritas sederhana node (untuk memaksimalkan jumlah kuorum yang berbeda). Dasar Eksperimen dasar kami mengukur Stellar dengan 100.000 akun, empat validator, dan pembuatan beban kecepatan 100 transaksi/detik. Kami mengamati rata-rata 507 transaksi per buku besar, dengan deviasi standar 49 (9,7%). Perhatikan bahwa tidak ada transaksi yang dibatalkan; sedikit 105 106 107 0 500 1.000 1.500 2.000 Akun Latensi [ms] Pembaruan buku besar Pemungutan suara Nominasi Gambar 9. Latensi seiring bertambahnya jumlah akun varians disebabkan oleh keterbatasan penjadwalan generator beban. Kami mengamati bahwa jumlah transaksi per buku besar konsisten dengan tingkat pembangkitan beban kami, berdasarkan buku besar menutup setiap 5 detik. Nominasi, pemungutan suara, dan buku besar pembaruan menunjukkan latensi rata-rata 82,53 ms, 95,96 ms, dan 174,08 ms, masing-masing. Kami mengamati latensi nominasi tersebut Persentil ke-99 secara konsisten berada di bawah 61 md, dan kadang-kadang lonjakan sekitar 1 detik, sesuai dengan langkah pertama dalam fungsi batas waktu pemilihan pemimpin. Mengingat kinerja dasar, kami melihat dampaknya memvariasikan setiap parameter pengaturan pengujian. Akun Data pada Gambar 9 menunjukkan bahwa skala Stellar serta jumlah akun bertambah. Generasi tes akun menjadi proses yang panjang, seiring pembuatan keranjang dan penggabungan mencegah kami untuk sekadar mengisi database dengan akun langsung melalui SQL. Oleh karena itu, kami melakukan eksperimen hingga 50.000.000 akun. Selagi ada dampak minimal pada konsensus dan latensi pembaruan buku besar, kami mencatat bahwa peningkatan akun menciptakan overhead sebesar menggabungkan ember, yang menjadi lebih besar. Tingkat transaksi Tingkat transaksi mempengaruhi jumlah lalu lintas multicast di antara validators, jumlah transaksi yang termasuk dalam setiap buku besar, dan ukuran tingkat teratas ember. Untuk memahami dampak peningkatan transaksi memuat, kami menjalankan eksperimen dengan 100.000 akun dan 4 validators. Gambar 10 menunjukkan pertumbuhan latensi konsensus yang lambat, sementara sebagian besar waktu dihabiskan untuk memperbarui buku besar. Tidak mengherankan, seiring bertambahnya ukuran kumpulan transaksi membutuhkan waktu lebih lama untuk mengkomitnya ke database. Kami juga mencatat itu latensi pembaruan buku besar sangat bergantung pada implementasi, dan dipengaruhi oleh pilihan database. Node validator Untuk melihat seberapa meningkat jumlah tierone validatorsmemengaruhi kinerja, kami menjalankan eksperimen dengan 100.000 akun, 100 transaksi/detik, dan jumlah validator yang bervariasi dari 4 hingga 43. Semua validator muncul di seluruh kuorum validators; irisan kuorum yang lebih kecil akan melakukannya memiliki dampak yang lebih kecil terhadap kinerja.SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada Lokhava dkk. 100 150 200 250 300 350 0 500 1.000 1.500 2.000 Muat [transaksi/detik] Latensi [ms] Pembaruan buku besar Pemungutan suara Nominasi Gambar 10. Latensi seiring meningkatnya beban transaksi 10 20 30 40 0 500 1.000 1.500 2.000 Validator Latensi [ms] Pembaruan buku besar Pemungutan suara Nominasi Gambar 11. Latensi seiring bertambahnya jumlah node Mengubah jumlah node validasi di jaringan berdampak pada jumlah pesan SCP yang dipertukarkan juga jumlah nilai potensial selama nominasi. Gambar 11 menunjukkan waktu nominasi meningkat pada tingkat yang relatif kecil. Meskipun data menunjukkan bahwa pemungutan suara adalah hambatannya, kami percaya bahwa banyak masalah penskalaan dapat diatasi dengan melakukan perbaikan Jaringan overlay Stellar untuk mengoptimalkan lalu lintas jaringan. Sebagai diharapkan, latensi pembaruan buku besar tetap independen jumlah node. Tingkat penutupan Terakhir, kami ingin mengukur kinerja end-to-end Stellar dengan mengukur seberapa sering buku besar dikonfirmasi dan apakah Stellar memenuhi target 5 detik tanpa membatalkan transaksi apa pun. Kami mengamati rata-rata buku besar ditutup waktu 5,03 detik, 5,10 detik, dan 5,15 detik seiring peningkatan akun entri, tingkat transaksi, dan jumlah node, masing-masing. Hasilnya menunjukkan bahwa Stellar dapat menutup buku besar secara konsisten di bawah beban tinggi. 7.4 Menjalankan validator Salah satu fitur penting Stellar adalah biayanya yang rendah menjalankan validator, karena jangkar harus dijalankan (atau dikontrak) validators untuk menegakkan finalitas. SDF menjalankan 3 validators produksi, semuanya pada instans AWS c5.large, yang memiliki dua inti, RAM 4 GiB dan CPU Intel(R) Xeon(R) Platinum 8124M @ Prosesor 3,00GHz. Memeriksa penggunaan sumber daya di satu tempat dari mesin ini, kami mengamati proses Stellar menggunakan sekitar 7% CPU dan 300 MiB memori. Dalam hal lalu lintas jaringan, dengan 28 koneksi ke rekan dan ukuran kuorum dari 34, kecepatan masuk dan keluar adalah 2,78 Mbit/s dan 2,56 Mbit/dtk, masing-masing. Perangkat keras diperlukan untuk menjalankan a prosesnya tidak mahal. Dalam kasus kami, biayanya adalah $0,054/jam atau sekitar $40/bulan. 7.5 Pekerjaan masa depan Eksperimen ini menunjukkan bahwa Stellar dapat dengan mudah menskalakan 1–2 pesanan besarnya melebihi penggunaan jaringan saat ini. Karena tuntutan kinerja sangat sederhana hingga saat ini, Stellar menyisakan ruang untuk banyak penggunaan pengoptimalan langsung teknik terkenal. Misalnya transaksi dan SCP pesan disiarkan oleh validators menggunakan banjir naif protokol, namun idealnya menggunakan protokol yang lebih efisien dan terstruktur multicast peer-to-peer [30]. Selain itu, banyak database waktu pembaruan buku besar dapat ditingkatkan melalui teknik batching dan prefetching standar.
Kesimpulan
Pembayaran internasional mahal dan memakan waktu berhari-hari. Dana hak asuh melewati beberapa lembaga keuangan termasuk bank koresponden dan layanan pengiriman uang. Karena setiap hop harus dipercaya sepenuhnya, sulit untuk yang baru pendatang untuk mendapatkan pangsa pasar dan bersaing. Stellar pertunjukan cara mengirim uang ke seluruh dunia dengan murah dalam hitungan detik. Itu inovasi utamanya adalah protokol perjanjian Bizantium keanggotaan terbuka baru, SCP, yang memanfaatkan struktur peer-to-peer jaringan keuangan untuk mencapai konsensus global berdasarkan a hipotesis Internet baru. SCP membiarkan Stellar berkomitmen secara atom transaksi yang tidak dapat diubah antar peserta sewenang-wenang yang tidak tahu atau percaya satu sama lain. Hal ini pada gilirannya menjamin akses pendatang baru ke pasar yang sama seperti yang sudah ada pemain, membuatnya aman untuk mendapatkan pertukaran terbaik yang tersedia bahkan dari pembuat pasar yang tidak tepercaya, dan secara dramatis mengurangi latensi pembayaran. Ucapan Terima Kasih Stellar tidak akan menjadi seperti sekarang ini tanpa adanya awal kepemimpinan Joyce Kim atau kontribusi luar biasa dari Scott Fleckenstein dan Bartek Nowotarski di gedung dan mempertahankan horizon, Stellar SDK, dan bagian penting lainnya ekosistem Stellar. Kami juga berterima kasih kepada Kolten Bergeron, Henry Corrigan-Gibbs, Candace Kelly, Kapil K. Jain, Boris Reznikov, Jeremy Rubin, Christian Rudder, Eric Saunders, Torsten Stüber, Tomer Weller, pengulas anonim, dan gembala kami Justine Sherry atas komentarnya yang bermanfaat draft sebelumnya. Penafian Kontribusi Profesor Mazières pada publikasi ini adalah sebagai konsultan berbayar, dan bukan merupakan bagian dari kontribusinya Tugas atau tanggung jawab Universitas Stanford.
Pembayaran global yang cepat dan aman dengan Stellar SOSP '19, 27–30 Oktober 2019, Huntsville, ON, Kanada
Pertanyaan yang Sering Diajukan
- Apa itu whitepaper Stellar?
- Whitepaper Stellar Consensus Protocol (SCP), yang ditulis oleh David Mazières pada tahun 2015, menggambarkan sistem federated Byzantine agreement yang memungkinkan konsensus terdesentralisasi tanpa memerlukan set validator tertutup atau penambangan proof-of-work.
- Siapa yang menulis whitepaper Stellar dan kapan?
- Whitepaper SCP ditulis oleh David Mazières, profesor Stanford dan kepala ilmuwan Stellar Development Foundation. Diterbitkan pada tahun 2015 sebagai makalah akademik formal.
- Apa inovasi teknis inti Stellar?
- Inovasi inti Stellar adalah Federated Byzantine Agreement (FBA) — model konsensus di mana setiap node memilih set kepercayaannya sendiri (quorum slice). Sistem ini menghasilkan konsensus global dari irisan keputusan kepercayaan individual, tanpa daftar validator yang telah ditentukan sebelumnya.
- Bagaimana mekanisme konsensus Stellar bekerja?
- Dalam SCP, setiap node memilih quorum slice dari rekan terpercaya. Konsensus dicapai melalui fase nominasi (mengusulkan nilai) dan fase ballot (menyepakati satu nilai). Irisan quorum memastikan keamanan bahkan tanpa otoritas global.
- Apa perbedaan Stellar dengan XRP?
- Stellar didirikan bersama oleh Jed McCaleb (yang juga mendirikan Ripple) namun menggunakan model konsensus yang pada dasarnya berbeda. FBA Stellar memungkinkan partisipasi terbuka dalam konsensus, sementara XRP mengharuskan validator berada dalam Unique Node List yang telah disepakati sebelumnya.
- Bagaimana model pasokan Stellar?
- Stellar memiliki pasokan tetap sebesar 50 miliar XLM (dikurangi dari 100 miliar setelah pemungutan suara komunitas untuk membakar 55 miliar). Tidak ada mekanisme inflasi. Biaya dasar kecil (0,00001 XLM) dikumpulkan dalam fee pool, tidak dibakar.
- Apa kegunaan utama Stellar?
- Stellar berfokus pada pembayaran lintas batas, tokenisasi aset, dan inklusi keuangan. Stellar mendukung koridor remitansi, menampung USDC secara native, serta memungkinkan penerbitan stablecoin, sekuritas, dan CBDC (central bank digital currencies).
- Masalah apa yang dipecahkan Stellar?
- Stellar memecahkan hambatan biaya dan kecepatan remitansi internasional, khususnya bagi masyarakat yang tidak memiliki rekening bank. Jaringannya memungkinkan penyelesaian dalam 3-5 detik dengan biaya sebagian kecil dari satu sen, sehingga pembayaran mikro menjadi layak secara ekonomi.
- Bagaimana model keamanan Stellar bekerja?
- Keamanan Stellar bergantung pada irisan quorum — tumpang tindih set kepercayaan di seluruh jaringan. Selama terdapat tumpang tindih yang cukup antara quorum slice, jaringan mempertahankan keamanan. Node individual dapat mentoleransi kegagalan rekan terpercaya mereka.
- Bagaimana kondisi ekosistem Stellar saat ini?
- Ekosistem Stellar mencakup integrasi MoneyGram, dukungan native USDC, Soroban (platform smart contract), dan kemitraan dengan lembaga keuangan di pasar berkembang. Stellar Development Foundation terus mendorong adopsi dalam pembayaran dan tokenisasi aset.