Salah Satu Pendiri Solana: Membangun Mesin Status Global dan Menganalisis Arsitektur Utama Solana

**Kata-kata: Anatoly Yakovenko, CEO (Co-Founder & CEO), Solana

Kompiler: 1912212.eth, Berita Pandangan ke Depan

Tujuan Solana adalah untuk menyinkronkan mesin keadaan global tunggal tanpa izin secepat mungkin, sesuai dengan hukum fisika. Saya percaya arsitektur yang akan dapat mencapai ini akan terlihat seperti ini:

• Sejumlah besar node penuh, lebih dari 10.000 (N > 10.000)

Agar jaringan berfungsi sebagai mesin keadaan global, ia perlu mendukung banyak node penuh. Turbin telah membuktikan bahwa replikasi cepat ke jaringan yang sangat besar dapat diskalakan pada perangkat keras dan jaringan modern.

• Sejumlah besar pemimpin generasi blok, lebih dari 10.000 (N > 10.000)
• Pemimpin bersamaan menghasilkan blok pada saat yang sama, dipilih secara acak dalam kisaran 4 hingga 16.

Concurrency Leader memungkinkan jaringan memiliki beberapa lokasi di seluruh dunia untuk memesan transaksi pengguna. Ini mengurangi jarak antara pengguna dan jaringan, menghilangkan kebutuhan untuk verifikasi node penuh sebelum transaksi ditambahkan ke rantai.

• Waktu blok adalah 120 milidetik

Waktu blok yang singkat menciptakan poin finalitas yang cepat, meningkatkan ketahanan sensor, meningkatkan pengalaman pengguna, mengurangi jendela untuk pemesanan ulang transaksi, dan mempercepat jaringan secara keseluruhan.

• Beberapa node konsensus pemungutan suara di subkomite persetujuan, dengan jumlah antara 200 dan 400, dipilih secara acak dan diputar setiap 4 hingga 8 jam per zaman.

Konsensus sangat penting untuk memilih garpu, yang terjadi karena partisi jaringan. Sampel 200 node atau lebih akan secara statistik mewakili semua partisi utama dalam jaringan dan sangat cocok dengan distribusi aktualnya. Oleh karena itu, semua suara node penuh tidak diperlukan, 200 sudah cukup. Batasi persetujuan untuk subkomite untuk mengurangi memori dan bandwidth jaringan yang diperlukan untuk mendukung blok 120 ms. Mengurangi waktu blok secara alami meningkatkan jumlah suara yang dikirim per detik, memberikan tekanan pada sumber daya yang dialokasikan untuk konsensus.

Tantangan sebenarnya di blok 120ms adalah memutar ulang semua transaksi pengguna. Karena jaringan tidak memiliki izin, sangat sulit untuk menjamin lingkungan eksekusi yang homogen dengan waktu yang dapat diandalkan untuk mengeksekusi kode pengguna yang sewenang-wenang. Meskipun ada kemungkinan, itu hanya dapat dicapai dengan membatasi sumber daya komputasi yang tersedia untuk transaksi pengguna dan memastikan bahwa setiap node dialokasikan secara berlebihan ke skenario terburuk.

Namun, tidak ada alasan untuk menegakkan status penuh untuk node konsensus yang memilih fork atau pemimpin yang membangun fork. Untuk menjaga persetujuan node konsensus dan pemimpin tetap sinkron, negara hanya perlu dihitung sekali per periode.

Eksekusi asinkron

Motivasi

Eksekusi sinkron mengharuskan semua node yang memilih dan membuat blok untuk dikonfigurasi secara super di blok mana pun untuk menentukan waktu eksekusi kasus terburuk. Eksekusi asinkron adalah salah satu dari sedikit kasus di mana ada beberapa trade-off. Node konsensus dapat melakukan lebih sedikit pekerjaan sebelum pemungutan suara. Pekerjaan dapat dikumpulkan dan dikelompokkan, sehingga efisien dalam eksekusi tanpa kehilangan cache. Bahkan dapat dieksekusi pada mesin yang sama sekali berbeda dari node konsensus atau pemimpin. Pengguna yang menginginkan eksekusi sinkron dapat mengalokasikan sumber daya perangkat keras yang cukup untuk melakukan setiap transisi status secara real-time tanpa harus menunggu seluruh jaringan.

Mengingat keragaman aplikasi dan pengembang inti, ada baiknya merencanakan perubahan protokol besar setiap tahun. Jika saya harus memilih satu, pilihan saya adalah mengeksekusi secara asinkron.

GAMBARAN UMUM

Saat ini, validator dengan cepat mengulangi semua transaksi pada setiap blok dan memberikan suara hanya setelah status lengkap dihitung untuk blok tersebut. Tujuan dari proposal ini adalah untuk memisahkan keputusan pemungutan suara pada garpu dari menghitung transisi negara penuh blok.

Validator yang memberikan suara dalam persetujuan hanya perlu memilih garpu; mereka tidak perlu melakukan status sama sekali. Hanya pada setiap zaman mereka memerlukan status untuk menghitung persetujuan berikutnya.

Prosedur pemungutan suara disesuaikan sehingga dapat dilakukan secara mandiri. Node menjalankan prosedur pemungutan suara hanya sebelum pemungutan suara. Karena validator tidak memakan banyak ruang, persyaratan memori harus relatif kecil. Karena pemungutan suara memiliki waktu pelaksanaan yang sangat dapat diprediksi, seharusnya ada sedikit atau tidak ada jitter dalam pelaksanaan prosedur pemungutan suara.

Semua transaksi non-voting dapat dihitung secara asinkron. Hal ini memungkinkan replay untuk mengeksekusi semua transaksi non-voting dalam batch, prefetch dan JIT semua program di muka, hampir menghilangkan semua kehilangan cache. Tujuan jangka panjangnya adalah hanya mesin yang memerlukan perhitungan real-time, latensi rendah, full-state yang akan dikonfigurasi untuk tugas ini. Agaknya, pengguna akan membayar untuk perangkat keras tambahan.

Setelah pemilihan fork dan eksekusi state dipisahkan, menjadi lebih mudah untuk mempercepat:

• Eksekusi asinkron
• Setiap zaman memutar sejumlah komite pemungutan suara
• Waktu blok 200 ms

Karena replay transaksi pengguna tidak memblokir pilihan fork, volatilitas tidak lagi menjadi masalah saat mengurangi waktu blok. Satu-satunya hal yang perlu dipertimbangkan adalah bahwa pada 200 milidetik, tingkat pemungutan suara validator berlipat ganda. Membuat perubahan yang cukup mudah tentang bagaimana kuota dihitung untuk persetujuan akan memungkinkan kami untuk memperbaiki ukuran persetujuan pada 200 atau 400, atau jumlah apa pun yang tampaknya sesuai.

Juga wajar untuk sepenuhnya memisahkan implementasi dari konsensus. Akan lebih cepat untuk memulai kembali node konsensus yang hanya perlu memeriksa akun program pemungutan suara dalam persetujuan ukuran tetap.

Bahkan, saya percaya bahwa waktu konfirmasi akan meningkat karena sebagian besar persetujuan dipilih secepat mungkin, dan sementara suara ini disebarkan, node yang memberi pengguna hasil eksekusi status penuh dapat melakukan transaksi pada saat yang bersamaan. Oleh karena itu, setiap jitter replay yang kita lihat hari ini harus terjadi bersamaan dengan propagasi jaringan pemungutan suara.

Suara

• Akun pemungutan suara harus memiliki jumlah SOL yang cukup untuk mencakup suara dari 2 zaman.
• Transaksi pemungutan suara harus sederhana. Pemungutan suara yang tidak sederhana pasti akan gagal. Generator blok harus melepaskan pemungutan suara yang rumit.
• Penarikan SOL dari akun pemungutan suara diperbolehkan, selama saldo tidak turun menjadi kurang dari 1 periode suara.
• Untuk menghilangkan semua lamport, arahan Vote CLOSE harus mengharuskan zaman penuh berlalu. Akun pemungutan suara ditandai sebagai TUTUP di Era 1, tetapi hanya dapat DITUTUP di Era 2. CLOSE memungkinkan Anda untuk menarik semua SOL dan menghapus akun pemungutan suara. Setelah akun ditandai sebagai TUTUP, akun hanya dapat dihapus sepenuhnya dan tidak dapat dibuka kembali.
• Suara berisi VoteBankHash bukan BankHash biasa.

Peraturan dan persetujuan pemimpin

Hanya validator yang memenuhi kriteria berikut:

• Jumlah taruhan > X
• Serta SOL > 2 zaman pemungutan suara
• dan tidak ditandai sebagai TUTUP

untuk memasukkan jadwal pemimpin dan menghitung persetujuan. Untuk versi 2, kita dapat memisahkan LeaderSchedule dari Kuorum, dan mereka tidak harus memiliki persyaratan yang sama masing-masing.

Perhitungan VoteBankHash

Tidak seperti Bankhash, yang menghitung semua transaksi, validator hanya menghitung VoteBankHash untuk transaksi pemungutan suara sederhana yang terkait dengan validator di LeaderScheduler. Semua transaksi lainnya diabaikan. Setelah memutar ulang semua suara, VoteBankHash dihitung dalam format yang sama dengan BankHash saat ini.

VoteBankHash harus mengakumulasi VoteBankHash sebelumnya, bukan BankHash penuh.

Perhitungan BankHash

Untuk semua blok yang dikonfirmasi optimis (dapat dikonfigurasi untuk semua blok), validator mulai menghitung UserBankHash, yang mencakup semua transisi status, tetapi tidak termasuk transaksi yang telah dipertimbangkan dalam perhitungan VoteBankHash.

BankHash kemudian diturunkan dari akumulasi (VoteBankHash, UserBankHash). 99,5% validator teratas mengirimkan BankHash sebagai bagian dari pemungutan suara mereka setiap 100 slot waktu. Sementara berkomitmen setiap 100 slot waktu, itu dihitung pada setiap slot waktu. Perlu dicatat bahwa mungkin bermanfaat bagi sebagian kecil node untuk secara konsisten mengirimkan BankHash dalam gosip sebagai sinyal lunak tanpa non-deterministik yang diamati.

Jika kurang dari 67% validator mengirimkan perhitungan BankHash penuh, pemimpin harus mengurangi ruang blok yang tersedia untuk transaksi pengguna dan akun yang dapat ditulis sebesar 50%. Langkah ini untuk melindungi rantai dari penyalahgunaan yang dapat meningkatkan waktu pemutaran ulang secara berlebihan.

BankHash harus mengakumulasi BankHash sebelumnya.

Pergi ke pemimpin bank

Selama pembuatan blok, kemungkinan pemimpin tidak akan dapat memperoleh status yang digunakan untuk membuat blok, dan tidak ideal untuk mengeksekusi semua transaksi selama periode pembuatan blok.

• Pemimpin menyimpan cache saldo akun berbayar.
• Jika akun berbayar digunakan sebagai sumber untuk transfer sistem, atau sebagai akun yang dapat ditulis yang diteruskan bersama dengan program sistem ke program lain, maka saldo akun berbayar diatur ke 0.
• Blok dikemas sesuai dengan unit komputasi yang dinyatakan (CU) dalam urutan prioritas biaya lokal hingga blok terisi.
• Biaya dipotong dari cache saldo akun berbayar.
• Caching saldo akun berbayar dilengkapi dengan perhitungan BankHash.

Jaringan menimbulkan biaya yang relatif kecil untuk kegagalan spam transaksi, hanya terdiri dari byte yang disimpan dalam arsip dan bandwidth yang diperlukan untuk menyebarkan transaksi di blok.

Mengingat bahwa validator sudah mencari untuk memaksimalkan penghasilan mereka, mereka memiliki banyak insentif untuk mempertahankan cache akun berbayar yang akurat. Selain itu, jika tidak ada penalti, siapa pun di jaringan apa pun dapat dengan mudah melayani cache dalam jangka panjang. Jika terjadi kerusakan server, operator pemimpin tanpa bank harus dapat dengan mudah beralih atau mengambil sampel dari berbagai sumber.

Ini berarti bahwa karena motivasi validator untuk memaksimalkan penghasilan, mereka akan berusaha untuk mempertahankan cache akun berbayar yang akurat. Dengan tidak adanya mekanisme penalti, cache ini dapat dilayani oleh node mana pun di jaringan untuk waktu yang lama. Selain itu, jika server gagal, operator tanpa pemimpin bank harus dapat dengan mudah beralih atau sampel dari berbagai sumber.

Trade-off

Trade-off utama adalah kurangnya tanda tangan pengakuan pada node penuh yang melayani status pengguna untuk mengonfirmasi bahwa status pengirimannya persis sama dengan sisa yang disetujui. Satu-satunya penjelasan otoritatif negara harus tetap sama, bahkan jika setiap transaksi diputar ulang secara berurutan dalam buku besar. Pengoptimalan kinerja apa pun tidak boleh mengubah hasil. Jadi, setelah fork diselesaikan, hanya status yang benar yang tersisa untuk dihitung, selama implementasi runtime bebas dari kesalahan.

Node yang dirancang untuk menyediakan state secara andal harus menjalankan beberapa mesin dan klien, dan jika ada perbedaan dalam eksekusi state, mereka harus berhenti beroperasi. Ini pada dasarnya adalah apa yang harus dilakukan operator hari ini, karena hanya mengandalkan sisa jaringan memperkenalkan sebagian besar asumsi integritas.

Pengguna juga dapat menandatangani transaksi yang menegaskan BankHash atau memicu pembatalan. Sisa jaringan akan mengeksekusi transaksi ini hanya jika BankHash yang dihitung persis sama dengan BankHash yang diberikan kepada pengguna oleh penyedia RPC.

Peta jalan simpul konsensus stateless jangka panjang

Jaringan dengan persetujuan ukuran tetap hanya memerlukan jumlah status yang sangat kecil untuk memulai. Persetujuan itu sendiri dan bobot janjinya, serta semua saldo akun pemungutan suara. Ini adalah jumlah memori yang sangat kecil dan file snapshot kecil yang dapat didistribusikan dengan cepat dan diinisialisasi dengan cepat pada reboot.

Jika persetujuan tidak konsisten dengan simpul penuh, simpul penuh yang melacak persetujuan dan status akan berhenti berjalan. Ini berarti bahwa jika ada ketidaksepakatan antara persetujuan dan status, pertukaran, saluran fiat, RPC, jembatan, dll., Semuanya akan berhenti berfungsi. Ini hanya membutuhkan persentase yang sangat kecil dari node konsensus stateless yang rusak.

Pemimpin tanpa bank dapat mengandalkan sampel beberapa node penuh untuk menyediakan cache saldo awal akun berbayar. Bahkan jika itu cacat, hasilnya akan menjadi spam di blok daripada kegagalan konsensus. Operator harus dapat memantau kesehatan pemimpin mereka dan persentase spam yang mereka suntikkan ke blok mereka, dan merespons kegagalan dengan cepat.