Versi dokumen orisinal: Ouroboros Genesis design update
Dipublikasikan pada tanggal 08 Mei 2024
Ditulis oleh Nicholas Frisby
Terjemahan ke dalam 
Bahasa Indonesia oleh @andreassosilo
(Translated to Indonesian language by @andreassosilo)
Pembaruan desain Ouroboros Genesis
08 Mei 2024 | Nicholas Frisby | bacaan 11 menit
Ouroboros Genesis adalah serangkaian peningkatan pada protokol Ouroboros yang sudah kuat, dengan langkah-langkah pengamanan untuk melindungi node jaringan pada saat baru atau kembali setelah absen.
Ouroboros adalah protokol konsensus yang menjadi inti dari blockchain Cardano. Mengingat perkembangan yang terus berlanjut dan peningkatan penggunaan Cardano, Ouroboros telah berkembang sesuai dengan jalur peningkatan yang direncanakan. Ouroboros Classic adalah protokol proof-of-stake pertama yang terbukti aman. Ouroboros BFT adalah solusi sementara yang memungkinkan pembaruan Byron. Ouroboros Praos melanjutkan pengembangan Ouroboros Classic. Evolusi Ouroboros akan melangkah lebih jauh dengan Ouroboros Genesis, yang saat ini direncanakan akan diluncurkan pada Q3 tahun 2024.
Kisah Ouroboros sejauh ini
Blockchain adalah buku besar terdistribusi (distributed ledger) yang direplikasi di seluruh mesin yang disebut node. Karena tidak ada otoritas pusat tunggal, diperlukan mekanisme untuk menjamin konsistensi dan ketidakberubahan (immutability) semua salinan buku besar. Mekanisme itu adalah protokol konsensus. Protokol ini juga menetapkan insentif bagi node untuk memvalidasi blok baru dan menambahkannya ke rantai (chain).
Ouroboros membagi waktu Cardano menjadi epoch, yang kemudian dibagi lagi menjadi slot. Slot mewakili periode waktu singkat ketika blok dapat dibuat.
Ouroboros Classic terbukti aman ketika sebagian besar node online dan memiliki salinan buku besar yang konsisten. Penyerang tidak dapat memprediksi node mana yang akan menjadi pemimpin slot / slot leader berikutnya (node yang mendapatkan kesempatan untuk menambahkan blok ke rantai), sehingga membuat serangan menjadi sangat mahal.
Ouroboros Praos meningkatkan keacakan (randomness) dalam pemilihan pemimpin slot berikutnya dan menambahkan langkah-langkah pencegahan untuk serangan lain yang mungkin terjadi.
Ouroboros Genesis akan menangani situasi di mana sebuah node pertama kali bergabung dengan jaringan (dimulai dari blok genesis), atau bergabung kembali setelah absen dalam waktu lama. Node-node seperti ini berada dalam situasi yang rentan sampai mereka mengejar ketinggalan. Misalnya, serangan long-range attack terjadi ketika seorang penyerang mencoba menulis ulang sejarah rantai. Penyerang mengumpulkan stake dalam jumlah besar, memungkinkan mereka secara diam-diam membuat blok lebih cepat daripada rantai utama (main chain). Kemudian, ketika rantai historis alternatif siap, penyerang mencoba mengalihkan rantai utama ke rantai penyerang. Implementasi Genesis akan mengurangi serangan jarak jauh / long-range attack, kecuali node yang sedang menyinkronisasi menjadi terkucil. Serangan eclipse terjadi ketika penyerang mencoba mengelilingi node korban dengan peer jahat, sehingga mengaburkan jaringan yang sebenarnya.
Perkembangan terbaru
Genesis memperkenalkan konsep-konsep baru berikut:
- ledger peers
- lightweight checkpointing (sebagai fallback/override sementara)
- limit on eagerness (LoE)
- genesis density disconnections (GDD)
- limit on patience (LoP)
- Genesis state machine.
Ledger peers
Perubahan terbesar dari makalah Genesis adalah keputusan arsitektural awal untuk mempertahankan batasan rollback node Praos. Di bawah Praos, node Cardano tidak akan melakukan rollback lebih dari 2.160 blok tanpa intervensi manual. Seperti yang diuraikan dalam makalah Genesis, sebuah node di bawah serangan eclipse hanya bisa memilih ekstensi dari rantai musuh selama bertahun-tahun dan kemudian, ketika akhirnya terhubung ke node yang melayani rantai jujur, tiba-tiba melakukan rollback pada sejumlah blok.
Karena dalam praktiknya tidak perlu bagi sebuah node memiliki kemampuan rollback tanpa batas, para arsitek memprioritaskan batas rollback, yang merupakan kunci bagi banyak batasan penggunaan sumber daya. Menghilangkannya untuk Genesis akan menghapus invarian penting yang digunakan oleh sebagian besar pekerjaan rekayasa sebelumnya. Selain itu, selama node sinkronisasi Cardano Genesis memiliki akses ke rekan (peer) yang jujur dan sehat, node tersebut seharusnya, seperti node Praos, tidak memerlukan rollback lebih dari 2160 blok.
Serangan eclipse berpotensi menjadi ancaman yang lebih signifikan bagi node Genesis daripada yang diungkapkan dalam makalah, yang tidak secara langsung membahasnya. Serangan-serangan ini membahayakan properti keamanan Genesis, karena eclipse yang berlangsung lebih dari beberapa detik sudah cukup untuk memungkinkan node sinkronisasi Genesis memilih 2.161 blok dari rantai musuh, meskipun telah menerapkan perbandingan kerapatan Genesis dengan setia. Tanpa pengetahuan tentang rantai yang jujur, aturan Genesis hanya akan memilih rantai terpadat yang saat ini dapat diakses. Dalam situasi eclipse, itu mungkin bukan rantai yang jujur. Ini berbeda dengan makalah Genesis, di mana node yang terkena eclipse dan penggunanya hanya mengalami penundaan, kebingungan, salah informasi, dan sebagainya. Hal ini membawa risiko terkait, tetapi tidak mengkompromikan properti keamanan atau kelangsungan hidup, karena node akhirnya dapat terhubung dengan rekan yang jujur dan pulih.
Mempertimbangkan hanya jaringan Praos, di mana node secara teoretis tidak pernah tertinggal, eclipse masih bisa merugikan. Perbedaan utama dengan Genesis adalah bahwa node Praos (yang secara inheren terbarui) dapat menahan eclipse yang jauh lebih lama sebelum ada kemungkinan signifikan bahwa node tersebut mungkin berkomitmen pada rantai musuh. Namun, bahkan tanpa mempertimbangkan kerentanan ekstra selama sinkronisasi, node Praos memang memerlukan beberapa pertahanan terhadap eclipse.
Salah satu pertahanannya adalah memperkenalkan konsep ledger peers dalam logika pemilihan peer untuk cukup membatasi kemungkinan dan durasi eclipse. Saat sinkronisasi, node Genesis menyesuaikan konfigurasi ledger peers untuk secara drastis mengurangi kemungkinan terkena eclipse. Dan tanpa adanya eclipse, node Genesis tidak akan pernah memilih 2161 blok dari rantai musuh.
Pemilihan rekan yang diubah akan bekerja seperti ini. Dengan memeriksa distribusi stake terbaru, sebuah node Genesis memilih sample peer yang telah berpartisipasi dalam memelihara jaringan, sehingga sangat mengurangi kemungkinan memilih node berbahaya
Rencana cadangan: lightweight checkpointing
Makalah Genesis menetapkan bahwa rantai terbaik dalam jaringan Praos yang sehat akan memiliki lebih banyak blok daripada rantai lainnya dalam jendela slot tetap segera setelah perpotongan kedua rantai. Satu-satunya pengecualian adalah jika jaringan Praos tidak sehat.
Pemadaman jaringan yang parah akan membenarkan pelaksanaan rencana pemulihan bencana, yang memerlukan kerja sama di luar jaringan di antara para pemangku kepentingan untuk menulis ulang rantai selama interval pemadaman guna memperbaiki rantai yang jujur. Setelah itu terjadi, aturan Genesis akan kembali menguntungkan rantai yang jujur.
Namun, rencana pemulihan bencana secara inheren sulit dan mahal untuk dilaksanakan. Setidaknya untuk sementara, mekanisme checkpointing sederhana akan memungkinkan subset operator stake pool yang waspada dan bekerja sama secara cukup besar untuk dengan cepat dan mudah mengendalikan jaringan selama atau segera setelah pemadaman produksi blok.
Logikanya sederhana dan konsisten dengan protokol yang lain: sebuah file konfigurasi yang menentukan daftar pasangan nomor blok dan hash, masing-masing menyebabkan blok lain dengan nomor blok yang sama dianggap tidak valid. Data konfigurasi checkpoint tersebut harus digunakan dengan hati-hati dan diperoleh hanya dari sumber yang terpercaya. Idealnya, pelaksanaan rencana pemulihan pada akhirnya akan memungkinkan (dan bahkan mengharuskan) bahwa penambahan reaktif ke daftar checkpoint bersifat sementara. Checkpoint permanen satu-satunya adalah set yang memastikan kunci genesis era Byron tidak lagi relevan dengan rantai Cardano.
Limit on eagerness (LoE)
Karena ledger peers secara efektif mencegah serangan eclipse, sebuah node yang sedang melakukan sinkronisasi dapat berasumsi bahwa ia memiliki setidaknya satu rekan sehat yang melayani semua bagian dari rantai yang jujur. Properti keamanan ini secara langsung dapat dipastikan dengan hanya melarang node sinkronisasi Genesis untuk memilih lebih dari 2160 blok dari sebuah rantai setelah perpotongan rantai rekan buku besarnya. Node tersebut hanya akan memilih blok yang disetujui oleh semua rekan buku besar, yang hampir pasti termasuk rekan yang jujur. Pembatasan ini disebut batas pada keaktifan (Limit on Eagerness atau LoE), karena node sinkronisasi tidak boleh dengan tergesa-gesa berkomitmen pada blok terbaik yang telah dilihatnya sejauh ini. Rekan yang sebenarnya musuh mungkin bisa menyajikan blok alternatifnya jauh lebih cepat daripada rekan jujur dalam hal menyajikan blok historis.
Genesis density disconnection
Sangat mudah bagi musuh untuk menyalahgunakan LoE sehingga menyebabkan korban berhenti menyinkronkan blok, melanggar properti keaktifan node yang sedang sinkronisasi. Ada tiga cara untuk melakukannya:
- Rekan penyerang mengklaim tidak memiliki blok lagi
- Rekan penyerang menyajikan rantai alternatif
- Rekan penyerang mengklaim memiliki blok alternatif tetapi juga tidak menyajikannya.
Aturan dasar dari makalah Genesis secara langsung mengurangi dampak dari dua yang pertama. Jika dua rekan menyajikan rantai yang berbeda dan setidaknya salah satu rantai memiliki tidak kurang dari 2161 blok setelah perpotongan, Genesis akan lebih memilih rantai yang memiliki lebih banyak blok dalam jendela slot tetap setelah perpotongan kedua rantai tersebut. (Rantai yang jujur akan selalu memenangkan perbandingan itu. Ingat bahwa prefiks bersama mencerminkan perpotongan rantai, bahkan jika salah satu rantai hanya merupakan perpanjangan dari yang lain.) Node Genesis akan memilih rantai yang jujur dengan memutuskan koneksi dari rekan yang lain. Tindakan ini dikenal sebagai pemutusan koneksi kerapatan Genesis (Genesis Density Disconnection atau GDD). Setelah cukup banyak GDD, perpotongan rekan yang tersisa akan lebih jauh di sepanjang rantai historis yang jujur.
Limit on patience (LoP)
Vektor serangan ketiga adalah yang paling sulit untuk dianalisis. GDD dinonaktifkan karena rekan tersebut mengklaim memiliki lebih banyak blok. Artinya, ia mengklaim bahwa jumlah bloknya dalam jendela tetap akan meningkat jika diizinkan lebih banyak waktu untuk menyajikan lebih banyak blok. Rekan yang jujur selalu benar-benar membuat klaim tersebut, sampai node sinkronisasi benar-benar memiliki semua blok yang jujur. Tetapi rekan penyerang dapat membuat klaim tersebut dengan itikad buruk. Batas kesabaran (Limit on Patience atau LoP) memastikan bahwa rekan yang mengklaim memiliki lebih banyak blok harus benar-benar mengirimkannya, dan melakukannya dengan segera. Komplikasi utamanya adalah bahwa bahkan rekan yang jujur pun tidak dapat mempertahankan responsivitas sempurna selama berjam-jam, mereka sesekali akan mengalami lonjakan latensi, dan sebagainya. Untuk alasan ini, LoP diimplementasikan sebagai ember bocor (leaky bucket) untuk setiap rekan, di mana kebocoran adalah laju pemrosesan blok sementara rekan tersebut telah mengklaim blok dan menyajikannya lebih lambat daripada beberapa tingkat minimum yang disepakati, tetapi kapasitas ember dari setiap rekan yang jujur akan cukup tinggi untuk menyerap lonjakan latensi yang biasanya diharapkan dari rekan buku besar yang sehat.
Genesis state machine
Node Genesis akan menonaktifkan LoE, GDD, dan LoP setelah menyimpulkan bahwa node tersebut telah sinkron, karena dua alasan penting. Pertama, node yang sudah sinkron dalam jaringan Praos pada dasarnya harus mencetak blok terbaik yang bisa dibuatnya dalam slot saat node tersebut terpilih. Sebagai contoh, jika node tersebut masih menggunakan aturan Genesis, penyerang yang kuat dapat memanfaatkan LoE untuk sementara melarang korban memilih blok yang baru saja dicetaknya, sehingga mencegah blok tersebut dari menyebar ke jaringan. Sulit untuk membatasi dampak sistemik dari vektor semacam itu, sehingga node Genesis harus berperilaku persis seperti node Praos kapan pun ia tidak sedang melakukan sinkronisasi.
Kedua, node yang sudah sinkron tidak memerlukan banyak rekan seperti node yang sedang sinkronisasi, karena tidak terlalu rentan terhadap serangan eclipse. Oleh karena itu, beban tambahan yang signifikan pada jaringan karena semua node mempertahankan jumlah ledger peers yang tinggi menjadi tidak perlu dan tidak diinginkan. Mesin status Genesis / Genesis state machine mengelola transisi node antara mempertimbangkan dirinya sinkron atau tidak:
• Saat sinkron, node menonaktifkan LoE, GDD, dan LoP.
• Node menyimpulkan bahwa ia telah sinkron jika kondisi-kondisi ini terpenuhi:
- Node memiliki cukup banyak rekan buku besar / ledger peers.
- Semua rekan mengklaim tidak memiliki blok tambahan (yang mana LoP yang disetel dengan baik memastikan hal ini terjadi segera).
- Node telah memilih rantai terbaik dari rekan-rekannya. Hal ini lebih kuat daripada mempercayai usia seleksi lokal, karena rekan penyerang mungkin dapat memicu ambang batas semacam itu, menyebabkan korban menurunkan pertahanannya secara prematur.
• Node kembali ke mode sinkronisasi jika ujung rantainya terlalu lama (misalnya, sekitar 20 menit). Perlu dicatat, hal ini akan terjadi selama proses sistem operasi node jika mesin tersebut tidur terlalu lama (misalnya, pengguna menutup penutup laptopnya untuk beberapa waktu).
Langkah selanjutnya
Desain di atas telah stabil selama sekitar setahun terakhir. Meskipun masih sedikit berkembang, tidak ada perubahan besar yang akan terjadi. IOG telah berkolaborasi dengan Tweag selama beberapa bulan terakhir untuk mengimplementasikan dan mengujinya.
Implementasi pertama yang mendukung Genesis dijadwalkan akan dirilis pada Q3 tahun 2024. Pada tahap ini, hal yang masih belum diketahui adalah tingkat optimasi yang diperlukan untuk mengimbangi peningkatan jumlah rekan yang dibutuhkan untuk mencegah serangan eclipse.
Sampai saat itu, desain bootstrap peer yang akan segera dirilis berfungsi sebagai langkah awal menuju Genesis. Bootstrap state machine adalah varian yang lebih sederhana dari Genesis state machine. Selama sinkronisasi, node hanya berkomunikasi dengan rekan bootstrap, yang semuanya dipercaya, sehingga LoE, GDD, dan LoP tidak diperlukan. Sebaliknya, Genesis akan memungkinkan node yang sedang sinkronisasi untuk dengan aman memasukkan bahkan rekan-rekan yang tidak dapat dipercaya (untrustworthy peers), asalkan tidak terserang eclipse (yaitu, selama ada satu rekan yang jujur), yang akan memungkinkan pensiunnya rekan-rekan bootstrap, sehingga mendesentralisasi infrastruktur untuk node sinkronisasi dan memenuhi janji Ouroboros Genesis.
Neil Burgess berkontribusi pada artikel ini.