Algoritma Konsensus Protokol Ripple
Abstract
Хотя существует несколько алгоритмов консенсуса для задачи Византийских генералов, в частности применительно к распределенным платежным системам, многие из них страдают от высокой задержки, вызванной необходимостью синхронного взаимодействия всех узлов сети. В данной работе мы представляем новый алгоритм консенсуса, который обходит это требование, используя коллективно доверенные подсети внутри более крупной сети. Мы показываем, что "доверие", необходимое для предотвращения атак Сивиллы (Sybil), на самом деле не является глобальным, а локальным для каждого узла сети.
Алгоритм консенсуса протокола Ripple (RPCA) применяется каждые несколько секунд всеми узлами для поддержания корректности и согласованности сети. После достижения консенсуса текущий леджер считается "закрытым" и становится последним закрытым леджером. Этот алгоритм уникален тем, что достигает консенсуса с низкой задержкой, сохраняя при этом надежные гарантии против византийских отказов, что делает его пригодным для систем финансовых расчетов в реальном времени.
Abstract
Meskipun sudah ada beberapa algoritma konsensus untuk Masalah Jenderal Bizantium, khususnya pada sistem pembayaran terdistribusi, banyak di antaranya mengalami latensi tinggi akibat persyaratan bahwa semua node dalam jaringan harus berkomunikasi secara sinkron. Dalam karya ini, kami memperkenalkan algoritma konsensus baru yang mengatasi persyaratan tersebut dengan memanfaatkan subjaringan yang dipercaya secara kolektif di dalam jaringan yang lebih besar. Kami menunjukkan bahwa "kepercayaan" yang diperlukan untuk mencegah serangan Sybil pada kenyataannya bukan bersifat global, melainkan lokal pada setiap node dalam jaringan.
Algoritma konsensus protokol Ripple (RPCA) diterapkan setiap beberapa detik oleh semua node untuk menjaga ketepatan dan keselarasan jaringan. Setelah konsensus tercapai, ledger saat ini dianggap "tertutup" dan menjadi ledger tertutup terakhir. Algoritma ini unik karena mampu mencapai konsensus dengan latensi rendah sambil mempertahankan jaminan kuat terhadap kegagalan Byzantine, sehingga cocok untuk sistem penyelesaian keuangan waktu nyata.
Introduction
Распределенная платежная система должна реализовывать алгоритм консенсуса для корректной и своевременной обработки платежей даже при наличии неисправных или злонамеренных участников. Bitcoin достигает консенсуса с помощью доказательства работы (proof-of-work), которое требует от всех узлов затрачивать вычислительные ресурсы на решение криптографических задач. Хотя этот подход обеспечивает надежные гарантии безопасности, он имеет существенные недостатки, включая высокое энергопотребление, низкую пропускную способность транзакций и длительные задержки подтверждения, которые могут достигать часа и более для транзакций высокой стоимости.
Алгоритм консенсуса протокола Ripple предлагает новый подход к распределенному консенсусу, не требующий доказательства работы. Вместо этого узлы сети коллективно согласовывают наборы транзакций посредством процесса голосования, который достигает консенсуса за считанные секунды. Этот механизм консенсуса разработан специально для требований глобальной платежной сети, где низкая задержка и высокая пропускная способность необходимы для практического развертывания.
Ключевое нововведение RPCA заключается в том, что он не требует согласия всех узлов сети друг с другом. Вместо этого каждый узел ведет Уникальный список узлов (Unique Node List, UNL) других узлов, которым он доверяет в том, что они не вступят в сговор. Пока выбранные узлами UNL имеют достаточное пересечение и менее порогового процента узлов являются неисправными, сеть достигнет консенсуса. Этот подход обеспечивает гарантии безопасности, необходимые для платежной системы, при этом достигая задержки консенсуса, измеряемой в секундах, а не в минутах или часах.
Introduction
Sistem pembayaran terdistribusi harus menerapkan algoritma konsensus agar pembayaran dapat diproses secara benar dan tepat waktu bahkan ketika ada pelaku yang rusak atau berniat jahat. Bitcoin mencapai konsensus menggunakan proof-of-work, yang mengharuskan semua node mengeluarkan sumber daya komputasi untuk memecahkan teka-teki kriptografis. Walaupun pendekatan ini memberikan jaminan keamanan yang kuat, pendekatan ini memiliki kelemahan signifikan, termasuk konsumsi energi tinggi, throughput transaksi rendah, serta latensi konfirmasi panjang yang dapat mencapai satu jam atau lebih untuk transaksi bernilai tinggi.
Algoritma konsensus protokol Ripple menawarkan pendekatan baru terhadap konsensus terdistribusi tanpa memerlukan proof-of-work. Sebagai gantinya, node dalam jaringan secara kolektif menyepakati himpunan transaksi melalui proses pemungutan suara yang mencapai konsensus dalam hitungan detik. Mekanisme ini dirancang khusus untuk kebutuhan jaringan pembayaran global, di mana latensi rendah dan throughput tinggi sangat penting untuk implementasi praktis.
Inovasi utama RPCA adalah tidak mengharuskan semua node dalam jaringan saling menyetujui secara langsung. Sebaliknya, setiap node memelihara Unique Node List (UNL) berisi node lain yang dipercaya tidak akan berkolusi. Selama UNL yang dipilih antar-node memiliki tumpang tindih yang memadai, dan persentase node yang rusak berada di bawah ambang tertentu, jaringan akan mencapai konsensus. Pendekatan ini menyediakan jaminan keamanan yang dibutuhkan sistem pembayaran sekaligus mencapai latensi konsensus dalam hitungan detik, bukan menit atau jam.
Definition of Consensus
В распределенных системах консенсус означает процесс, посредством которого сеть узлов приходит к согласию относительно общего состояния, несмотря на наличие неисправных или злонамеренных участников. Алгоритм консенсуса должен удовлетворять трем фундаментальным свойствам: корректность (никакие два правильных узла не принимают разных решений), согласие (все правильные узлы приходят к одному решению) и завершение (все правильные узлы в конечном итоге принимают решение). Эти свойства обеспечивают поведение распределенной системы так, как если бы она была единым надежным узлом.
Сложность достижения консенсуса обусловлена присущей ненадежностью распределенных систем. Узлы могут выходить из строя, сообщения могут задерживаться или теряться, а византийские узлы могут вести себя произвольно или злонамеренно. Задача Византийских генералов, формализованная Лэмпортом, Шостаком и Пизом, отражает эту проблему: как группа процессов может достичь согласия, когда некоторая доля может быть неисправной, а связь ненадежна?
Классические результаты в области распределенных вычислений устанавливают фундаментальные пределы того, чего могут достичь алгоритмы консенсуса. Результат невозможности FLP показывает, что ни один детерминированный алгоритм не может гарантировать консенсус в асинхронной системе, если хотя бы один узел может отказать. Поэтому практические алгоритмы консенсуса должны идти на компромисс между безопасностью (никогда не достигать неверного консенсуса) и живучестью (всегда продвигаться вперед). Proof-of-work Bitcoin отдает приоритет безопасности над живучестью, тогда как RPCA достигает баланса, более подходящего для платежных систем, завершая раунды консенсуса за ограниченное время при сохранении надежных гарантий безопасности в рамках реалистичных предположений о сбоях.
Definition of Consensus
Dalam sistem terdistribusi, konsensus merujuk pada proses ketika jaringan node mencapai kesepakatan atas satu keadaan bersama, meskipun ada peserta yang rusak atau berniat jahat. Algoritma konsensus harus memenuhi tiga sifat fundamental: correctness (dua node benar tidak boleh memutuskan hal yang berbeda), agreement (semua node benar mencapai keputusan yang sama), dan termination (semua node benar pada akhirnya mengambil keputusan). Sifat-sifat ini memastikan sistem terdistribusi berperilaku seolah-olah merupakan satu node tunggal yang andal.
Tantangan utama dalam mencapai konsensus berasal dari sifat tidak andal bawaan pada sistem terdistribusi. Node dapat crash, pesan dapat tertunda atau hilang, dan node Byzantine dapat bertindak sewenang-wenang atau jahat. Masalah Jenderal Bizantium, yang diformalkan oleh Lamport, Shostak, dan Pease, menangkap tantangan ini: bagaimana sekelompok proses mencapai kesepakatan ketika sebagian dapat rusak dan komunikasi tidak andal?
Hasil-hasil klasik dalam komputasi terdistribusi menetapkan batas dasar atas apa yang dapat dicapai oleh algoritma konsensus. Hasil ketidakmungkinan FLP menunjukkan bahwa tidak ada algoritma deterministik yang dapat menjamin konsensus dalam sistem asinkron jika bahkan satu node saja dapat gagal. Karena itu, algoritma konsensus praktis harus membuat trade-off antara safety (tidak pernah mencapai konsensus yang salah) dan liveness (selalu terus maju). Proof-of-work Bitcoin memprioritaskan safety dibanding liveness, sementara RPCA mencapai keseimbangan yang lebih sesuai untuk sistem pembayaran dengan menyelesaikan ronde konsensus dalam waktu terbatas sambil mempertahankan jaminan safety yang kuat di bawah asumsi kegagalan yang realistis.
Existing Consensus Algorithms
Для решения задачи Византийских генералов в распределенных системах было предложено несколько алгоритмов консенсуса. Алгоритм Practical Byzantine Fault Tolerance (PBFT), представленный Кастро и Лисков, может допускать до f византийских сбоев в системе из 3f+1 узлов. PBFT достигает консенсуса через несколько раундов обмена сообщениями между всеми узлами со сложностью коммуникации O(n^2), где n -- количество узлов. Хотя PBFT обеспечивает надежные гарантии безопасности и относительно низкую задержку для небольших сетей, он плохо масштабируется для больших сетей из-за квадратичных накладных расходов на коммуникацию.
Paxos и его варианты, разработанные Лэмпортом, обеспечивают консенсус в асинхронных системах, но предполагают отказы по сбою, а не византийские отказы. Paxos достигает консенсуса через серию раундов, в которых предлагающие узлы выдвигают значения, а принимающие узлы голосуют за них. Хотя Paxos может допускать произвольные задержки сообщений и отказы процессов, он требует тщательной инженерии для обработки византийских отказов и может страдать от livelock в определенных сценариях.
Алгоритм консенсуса proof-of-work Bitcoin использует принципиально иной подход, делая византийские атаки экономически нецелесообразными. Узлы соревнуются в решении криптографических задач, при этом победитель предлагает следующий блок транзакций. Хотя этот подход масштабируется до произвольных размеров сети и справляется с византийскими отказами, он имеет серьезные недостатки: огромное потребление энергии (оценивается более чем в 150 миллионов долларов в год для сети Bitcoin), длительные задержки подтверждения (часто 40-60 минут для транзакций высокой стоимости) и ограниченная пропускная способность (приблизительно 7 транзакций в секунду). Эти ограничения делают proof-of-work непригодным для многих приложений платежных систем, требующих быстрого расчета и больших объемов транзакций.
Existing Consensus Algorithms
Sejumlah algoritma konsensus telah diusulkan untuk menyelesaikan Masalah Jenderal Bizantium dalam sistem terdistribusi. Algoritma Practical Byzantine Fault Tolerance (PBFT), yang diperkenalkan oleh Castro dan Liskov, mampu menoleransi hingga f kesalahan Byzantine dalam sistem berisi 3f+1 node. PBFT mencapai konsensus melalui beberapa ronde pertukaran pesan antar semua node, dengan kompleksitas komunikasi O(n^2), di mana n adalah jumlah node. Meskipun PBFT memberikan jaminan safety yang kuat dan latensi relatif rendah untuk jaringan kecil, PBFT tidak berskala baik pada jaringan besar karena overhead komunikasi kuadratik.
Paxos dan variannya, yang dikembangkan oleh Lamport, menyediakan konsensus dalam sistem asinkron tetapi mengasumsikan kegagalan crash, bukan kegagalan Byzantine. Paxos mencapai konsensus melalui serangkaian ronde ketika proposer mengusulkan nilai dan acceptor memberikan suara. Walaupun Paxos dapat mentoleransi penundaan pesan arbitrer dan crash proses, Paxos memerlukan rekayasa yang cermat untuk menangani kegagalan Byzantine dan dapat mengalami livelock pada skenario tertentu.
Algoritma konsensus proof-of-work Bitcoin mengambil pendekatan yang secara fundamental berbeda, yakni membuat serangan Byzantine tidak layak secara ekonomi. Node bersaing memecahkan teka-teki kriptografis, dan pemenang mengusulkan blok transaksi berikutnya. Walaupun pendekatan ini dapat diskalakan ke ukuran jaringan arbitrer dan menangani kegagalan Byzantine, pendekatan ini memiliki kekurangan serius: konsumsi energi masif (diperkirakan lebih dari 150 juta dolar AS per tahun untuk jaringan Bitcoin), latensi konfirmasi panjang (sering 40-60 menit untuk transaksi bernilai tinggi), dan throughput terbatas (sekitar 7 transaksi per detik). Keterbatasan ini membuat proof-of-work kurang cocok bagi banyak aplikasi sistem pembayaran yang memerlukan penyelesaian cepat dan volume transaksi tinggi.
Ripple Protocol Consensus Algorithm
Алгоритм консенсуса протокола Ripple (RPCA) начинается с того, что каждый сервер берет все действительные транзакции, которые он видел и которые еще не были применены, в качестве транзакций-кандидатов. Затем серверы следуют многораундовому протоколу, в котором они итеративно работают над достижением согласия относительно набора транзакций, которые должны быть применены к текущему леджеру. В каждом раунде серверы делают предложения, состоящие из транзакций, которые, по их мнению, должны быть включены в следующий леджер.
В ходе каждого раунда консенсуса серверы передают свои предложения другим серверам из своего Уникального списка узлов (Unique Node List, UNL). Затем серверы вычисляют, какие транзакции появляются в пороговом проценте предложений. Изначально этот порог установлен на уровне 50%, что означает, что транзакция должна появиться в предложениях как минимум половины UNL сервера, чтобы быть рассмотренной в следующем раунде. По мере продвижения консенсуса через последовательные раунды этот порог увеличивается поэтапно (обычно до 60%, 70% и, наконец, 80%).
Когда транзакция достигает порога квалифицированного большинства в 80% поддержки в UNL сервера, она включается в предложение этого сервера для финального раунда консенсуса. Все транзакции, достигшие этого порога по всей сети, применяются к леджеру, который затем криптографически хешируется и подписывается. Этот вновь подтвержденный леджер становится последним закрытым леджером, и процесс начинается заново с новым набором транзакций-кандидатов.
Процесс консенсуса обычно завершается за 5 секунд или менее, при этом большинству транзакций требуется только один раунд консенсуса для достижения порога квалифицированного большинства. Транзакции, не достигшие консенсуса за один раунд, остаются кандидатами для последующих раундов. Такая конструкция обеспечивает непрерывный прогресс сети при сохранении надежных гарантий безопасности, поскольку ни одна транзакция не может быть применена к леджеру без поддержки квалифицированного большинства доверенных валидаторов.
Ripple Protocol Consensus Algorithm
Ripple Protocol Consensus Algorithm (RPCA) dimulai dengan setiap server mengambil semua transaksi valid yang telah dilihat tetapi belum diterapkan sebagai transaksi kandidat. Server kemudian mengikuti protokol multi-ronde, bekerja secara iteratif menuju kesepakatan atas himpunan transaksi yang akan diterapkan ke ledger saat ini. Pada setiap ronde, server membuat proposal yang terdiri dari transaksi yang menurut mereka perlu dimasukkan ke ledger berikutnya.
Selama setiap ronde konsensus, server mengomunikasikan proposalnya ke server lain dalam Unique Node List (UNL) mereka. Server lalu menghitung transaksi mana yang muncul dalam persentase ambang proposal. Pada awalnya, ambang ini ditetapkan di 50%, artinya transaksi harus muncul dalam proposal dari setidaknya setengah UNL server agar dipertimbangkan pada ronde berikutnya. Seiring konsensus berkembang melalui ronde berturut-turut, ambang ini meningkat secara bertahap (umumnya menjadi 60%, 70%, dan akhirnya 80%).
Ketika transaksi mencapai ambang supermajority 80% dukungan dalam UNL server, transaksi tersebut dimasukkan ke proposal server untuk ronde konsensus akhir. Semua transaksi yang mencapai ambang ini di seluruh jaringan diterapkan ke ledger, lalu ledger di-hash dan ditandatangani secara kriptografis. Ledger yang baru divalidasi ini menjadi ledger tertutup terakhir, dan proses dimulai kembali dengan himpunan transaksi kandidat berikutnya.
Proses konsensus biasanya selesai dalam 5 detik atau kurang, dengan sebagian besar transaksi hanya membutuhkan satu ronde konsensus untuk mencapai ambang supermajority. Transaksi yang belum mencapai konsensus dalam satu ronde tetap menjadi kandidat untuk ronde berikutnya. Desain ini memastikan jaringan terus membuat kemajuan sambil mempertahankan jaminan safety yang kuat, karena tidak ada transaksi yang dapat diterapkan ke ledger tanpa dukungan supermajority dari validator tepercaya.
Formal Analysis of Convergence
Корректность RPCA критически зависит от пересечения между UNL, выбранными различными узлами сети. Пусть UNL_i обозначает уникальный список узлов узла i, а UNL_i ∩ UNL_j представляет множество узлов, которые присутствуют как в UNL_i, так и в UNL_j. Для того чтобы сеть поддерживала консенсус, мы требуем, чтобы для любых двух узлов i и j пересечение их UNL было достаточно большим относительно максимального размера любого из UNL.
В частности, протокол гарантирует безопасность, когда |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 для всех пар узлов i и j. Это условие обеспечивает, что даже если византийские узлы попытаются привести различные части сети к различным решениям консенсуса, пересечение доверенных узлов предотвращает форк. Если это условие выполняется и менее 1/5 узлов в любом UNL являются византийскими, то все корректные узлы придут к одному и тому же решению консенсуса.
Формальное доказательство проводится путем демонстрации того, что если бы два узла могли прийти к различным решениям консенсуса, должна была бы существовать транзакция T, которая присутствует в финальном леджере одного узла, но не другого. Для этого T должна была бы получить 80% поддержки в UNL первого узла, но менее 80% поддержки в UNL второго узла. Однако, учитывая требование пересечения и ограничение на византийские узлы, можно показать, что этот сценарий невозможен: если T достигает 80% поддержки в UNL_i, она должна достичь как минимум 60% поддержки в любом UNL_j, удовлетворяющем условию пересечения, и при достаточном количестве раундов консенсуса это сойдется к 80% или будет отклонено обоими узлами.
Свойство живучести -- что консенсус в конечном итоге будет достигнут -- следует из наблюдения, что порог включения детерминированно возрастает через раунды консенсуса. Даже при наличии византийских узлов и сетевых задержек протокол обеспечивает, что транзакции, поддержанные квалифицированным большинством честных узлов, в конечном итоге будут включены, тогда как транзакции без такой поддержки будут исключены. Ограниченное время для консенсуса (обычно 5 секунд) обеспечивает практические гарантии живучести, подходящие для приложений платежных систем.
Formal Analysis of Convergence
Kebenaran RPCA sangat bergantung pada tingkat tumpang tindih antara UNL yang dipilih oleh node-node berbeda dalam jaringan. Misalkan UNL_i menyatakan unique node list milik node i, dan UNL_i ∩ UNL_j menyatakan himpunan node yang muncul pada UNL_i dan UNL_j sekaligus. Agar jaringan mempertahankan konsensus, untuk setiap pasangan node i dan j, irisan UNL keduanya harus cukup besar relatif terhadap ukuran UNL yang lebih besar.
Secara spesifik, protokol menjamin safety ketika |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 untuk semua pasangan node i dan j. Kondisi ini memastikan bahwa sekalipun node Byzantine berusaha membuat bagian-bagian jaringan mencapai keputusan konsensus yang berbeda, tumpang tindih node tepercaya mencegah terjadinya fork. Jika kondisi ini terpenuhi dan kurang dari 1/5 node dalam setiap UNL bersifat Byzantine, maka semua node benar akan mencapai keputusan konsensus yang sama.
Pembuktian formal menunjukkan bahwa jika dua node dapat mencapai keputusan konsensus berbeda, harus ada transaksi T yang muncul di ledger final satu node tetapi tidak pada node lainnya. Agar hal ini terjadi, T harus mencapai dukungan 80% di UNL node pertama namun kurang dari 80% di UNL node kedua. Namun, dengan syarat tumpang tindih dan batas node Byzantine, skenario ini terbukti mustahil: jika T mencapai 80% dukungan di UNL_i, T harus mencapai setidaknya 60% dukungan di UNL_j mana pun yang memenuhi kondisi tumpang tindih, dan dengan ronde konsensus yang cukup, dukungan ini akan konvergen ke 80% atau ditolak oleh kedua node.
Properti liveness, yaitu konsensus pada akhirnya tercapai, berasal dari pengamatan bahwa ambang inklusi meningkat secara deterministik sepanjang ronde konsensus. Bahkan dengan keberadaan node Byzantine dan keterlambatan jaringan, protokol memastikan transaksi yang didukung supermajority node jujur pada akhirnya akan dimasukkan, sementara transaksi yang tidak memiliki dukungan tersebut akan dikeluarkan. Waktu konsensus yang terbatas (umumnya sekitar 5 detik) memberikan jaminan liveness praktis yang sesuai untuk aplikasi sistem pembayaran.
Unique Node Lists
Уникальный список узлов (Unique Node List, UNL) является фундаментальным компонентом RPCA, который отличает его от других алгоритмов консенсуса. Каждый узел в сети Ripple ведет UNL, состоящий из других узлов, которым он доверяет в том, что они не вступят в сговор для обмана сети. Критически важно, что это доверие является локальным, а не глобальным: разные узлы могут иметь разные UNL, и нет требования глобально согласованного набора валидаторов. Такая конструкция позволяет сети масштабироваться органически при сохранении децентрализации.
UNL служит механизмом предотвращения атак Сивиллы (Sybil) без необходимости доказательства работы. В наивной системе голосования злоумышленник мог бы создать множество псевдонимных узлов для получения непропорционального влияния. Требуя от каждого узла явного выбора тех узлов, которым он доверяет, RPCA гарантирует, что создание дополнительных идентичностей не дает преимущества, если только эти идентичности не смогут убедить существующие узлы добавить их в свои UNL. Это переносит проблему устойчивости к атакам Сивиллы с вычислительных затрат на репутацию и доверительные отношения.
Для корректного функционирования сети UNL должны быть выбраны таким образом, чтобы иметь достаточное пересечение, как описано в формальном анализе. На практике это означает, что хотя каждый оператор узла имеет автономию в выборе своего UNL, он должен обеспечить, чтобы его список включал валидаторов, которым также доверяют другие части сети. Ripple предоставляет UNL по умолчанию, состоящий из валидаторов, управляемых разнообразными организациями, но операторы узлов вольны модифицировать этот список на основе собственной оценки доверия.
Механизм UNL также обеспечивает естественный путь к прогрессивной децентрализации. На ранних этапах сети более централизованный набор валидаторов может быть уместен для обеспечения стабильности и надежности. По мере созревания сети и демонстрации своей надежности разнообразными операторами UNL могут эволюционировать, включая более широкий набор валидаторов, увеличивая устойчивость и децентрализацию сети без ущерба для ее свойств безопасности.
Unique Node Lists
Unique Node List (UNL) adalah komponen fundamental RPCA yang membedakannya dari algoritma konsensus lain. Setiap node dalam jaringan Ripple memelihara UNL yang berisi node lain yang dipercaya tidak akan berkolusi untuk menipu jaringan. Hal kritisnya adalah kepercayaan ini bersifat lokal, bukan global: node yang berbeda dapat memiliki UNL yang berbeda, dan tidak ada keharusan atas satu set validator yang disepakati secara global. Desain ini memungkinkan jaringan bertumbuh secara organik sambil tetap mempertahankan desentralisasi.
UNL berfungsi sebagai mekanisme pencegahan serangan Sybil tanpa membutuhkan proof-of-work. Dalam sistem voting naif, penyerang bisa membuat banyak identitas pseudonim untuk memperoleh pengaruh berlebihan. Dengan mengharuskan setiap node secara eksplisit memilih node mana yang dipercaya, RPCA memastikan pembuatan identitas tambahan tidak memberi keuntungan kecuali identitas tersebut dapat meyakinkan node yang ada untuk memasukkannya ke UNL mereka. Dengan demikian, masalah ketahanan Sybil bergeser dari pengeluaran komputasi ke reputasi dan relasi kepercayaan.
Agar jaringan berfungsi dengan benar, UNL harus dipilih sehingga memiliki tumpang tindih yang memadai, sebagaimana dijelaskan dalam analisis formal. Dalam praktiknya, ini berarti meskipun setiap operator node memiliki otonomi untuk memilih UNL sendiri, mereka harus memastikan daftar tersebut mencakup validator yang juga dipercaya oleh bagian lain jaringan. Ripple menyediakan UNL default yang terdiri dari validator yang dioperasikan oleh entitas beragam, tetapi operator node bebas menyesuaikan daftar ini berdasarkan penilaian kepercayaan mereka sendiri.
Mekanisme UNL juga menyediakan jalur alami menuju desentralisasi progresif. Pada tahap awal jaringan, kumpulan validator yang lebih terpusat mungkin tepat untuk memastikan stabilitas dan keandalan. Saat jaringan matang dan operator yang lebih beragam membuktikan kredibilitasnya, UNL dapat berevolusi untuk mencakup kumpulan validator yang lebih luas, meningkatkan ketahanan dan desentralisasi jaringan tanpa mengorbankan properti keamanannya.
Simulation Code
Для валидации теоретического анализа RPCA и оценки его производительности в различных условиях были проведены обширные симуляции с использованием специально разработанного программного обеспечения для моделирования. Среда моделирования представляет сеть узлов, каждый из которых ведет собственный UNL и участвует в протоколе консенсуса. Код реализует полный алгоритм RPCA, включая предложение транзакций, раунды голосования с возрастающими порогами и валидацию леджера.
Ключевые параметры, варьировавшиеся в симуляциях, включают размер сети (от 10 до 1 000 узлов), процент византийских узлов (от 0% до 20%), размер UNL (обычно от 5 до 50 узлов) и конфигурации топологии сети. Для каждой конфигурации параметров было проведено несколько запусков симуляции с различными случайными начальными значениями для обеспечения статистической достоверности результатов. В симуляциях отслеживались такие метрики, как задержка консенсуса, вероятность форка и пропускная способность транзакций.
Результаты моделирования подтверждают теоретические предсказания относительно сходимости и безопасности. Во всех конфигурациях, где условие пересечения UNL было выполнено и византийские узлы составляли менее 20% каждого UNL, сеть успешно достигала консенсуса без форков. Задержка консенсуса оставалась стабильно низкой (обычно завершаясь за 3-5 смоделированных секунд) независимо от размера сети, демонстрируя масштабируемость алгоритма. Даже при 15% византийских узлов, активно пытающихся нарушить консенсус, сеть сохраняла корректность при выполнении требования пересечения UNL.
Дополнительные симуляции исследовали граничные случаи и сценарии отказов, включая разделение сети, внезапные изменения состава UNL и координированные атаки византийских узлов. Эти симуляции предоставили информацию о надежности протокола и определили рекомендуемые лучшие практики для выбора UNL и эксплуатации сети. Полный код моделирования был предоставлен для независимой верификации и дальнейших исследований.
Simulation Code
Untuk memvalidasi analisis teoritis RPCA dan mengevaluasi kinerjanya di berbagai kondisi, simulasi ekstensif dilakukan menggunakan perangkat lunak simulasi khusus. Kerangka simulasi memodelkan jaringan node, masing-masing memelihara UNL sendiri dan berpartisipasi dalam protokol konsensus. Kode tersebut mengimplementasikan algoritma RPCA secara lengkap, termasuk proposal transaksi, ronde voting dengan ambang yang meningkat, dan validasi ledger.
Parameter kunci yang divariasikan dalam simulasi meliputi ukuran jaringan (dari 10 hingga 1.000 node), persentase node Byzantine (dari 0% hingga 20%), ukuran UNL (umumnya antara 5 dan 50 node), serta konfigurasi topologi jaringan. Untuk setiap konfigurasi parameter, beberapa kali simulasi dijalankan dengan random seed berbeda untuk memastikan validitas statistik hasil. Simulasi melacak metrik seperti latensi konsensus, probabilitas fork, dan throughput transaksi.
Hasil simulasi mengonfirmasi prediksi teoritis mengenai konvergensi dan safety. Pada semua konfigurasi ketika kondisi tumpang tindih UNL terpenuhi dan node Byzantine kurang dari 20% dari setiap UNL, jaringan berhasil mencapai konsensus tanpa fork. Latensi konsensus tetap rendah secara konsisten (umumnya selesai dalam 3-5 detik simulasi) terlepas dari ukuran jaringan, menunjukkan skalabilitas algoritma. Bahkan dengan 15% node Byzantine yang aktif mencoba mengganggu konsensus, jaringan tetap mempertahankan correctness selama syarat tumpang tindih UNL terpenuhi.
Simulasi tambahan mengeksplorasi kasus tepi dan skenario kegagalan, termasuk partisi jaringan, perubahan mendadak komposisi UNL, serta serangan terkoordinasi oleh node Byzantine. Simulasi ini memberikan wawasan tentang ketangguhan protokol dan menjadi dasar rekomendasi praktik terbaik untuk pemilihan UNL serta operasi jaringan. Kode simulasi lengkap telah dipublikasikan untuk memungkinkan verifikasi independen dan riset lanjutan.
Discussion
По сравнению с консенсусом proof-of-work Bitcoin, RPCA предлагает несколько значительных преимуществ для приложений платежных систем. Наиболее примечательно, что задержка консенсуса сокращается с 40-60 минут (время, обычно рекомендуемое для высокостоимостных транзакций Bitcoin) до примерно 5 секунд. Это улучшение делает RPCA пригодным для точек продаж и других приложений, где требуется практически мгновенный расчет. Кроме того, RPCA требует минимальных вычислительных ресурсов по сравнению с proof-of-work, устраняя огромное потребление энергии, связанное с майнингом Bitcoin.
Однако эти преимущества сопряжены с иными предположениями о доверии. В то время как безопасность Bitcoin основывается только на предположении, что ни один злоумышленник не контролирует более 50% вычислительной мощности сети, RPCA требует, чтобы узлы выбирали UNL с достаточным пересечением и чтобы византийские узлы не превышали порог в этих UNL. Это перекладывает часть ответственности на операторов узлов за принятие разумных решений о доверии. На практике этот компромисс приемлем для многих случаев использования платежных систем, где участвующие учреждения имеют существующие доверительные отношения.
Топология сети и стратегия выбора UNL существенно влияют на свойства системы консенсуса. Высокоцентрализованная топология, при которой все узлы включают одних и тех же валидаторов в свои UNL, максимизирует безопасность, но может снизить живучесть, если эти валидаторы станут недоступными. И наоборот, высокодецентрализованная топология с минимальным пересечением UNL может улучшить живучесть, но рискует привести к сбоям консенсуса, если пересечение станет слишком малым. Нахождение оптимального баланса требует тщательного рассмотрения конкретного сценария развертывания и допустимого уровня риска.
Будущие работы могут исследовать адаптивные алгоритмы выбора UNL, которые автоматически поддерживают требования пересечения при максимизации децентрализации, механизмы для динамической корректировки UNL узлами на основе наблюдаемого поведения валидаторов и расширения алгоритма консенсуса, которые могли бы допускать еще более высокие доли византийских узлов. Эти улучшения могут дополнительно повысить надежность и применимость RPCA для крупномасштабных распределенных платежных систем.
Discussion
Dibandingkan konsensus proof-of-work pada Bitcoin, RPCA menawarkan sejumlah keunggulan penting untuk aplikasi sistem pembayaran. Yang paling menonjol, latensi konsensus turun dari 40-60 menit (waktu yang umumnya direkomendasikan untuk transaksi Bitcoin bernilai tinggi) menjadi sekitar 5 detik. Peningkatan ini membuat RPCA cocok untuk point-of-sale dan aplikasi lain yang membutuhkan penyelesaian hampir seketika. Selain itu, RPCA memerlukan sumber daya komputasi minimal dibanding proof-of-work, sehingga menghilangkan konsumsi energi masif yang terkait dengan penambangan Bitcoin.
Namun, keunggulan ini datang dengan asumsi kepercayaan yang berbeda. Keamanan Bitcoin bergantung pada asumsi bahwa tidak ada penyerang yang mengendalikan lebih dari 50% daya komputasi jaringan, sedangkan RPCA mensyaratkan node memilih UNL dengan tumpang tindih memadai dan node Byzantine tidak melampaui ambang di dalam UNL tersebut. Hal ini memindahkan sebagian tanggung jawab kepada operator node untuk membuat keputusan kepercayaan yang bijak. Dalam praktik, trade-off ini dapat diterima untuk banyak kasus penggunaan pembayaran ketika institusi yang berpartisipasi sudah memiliki hubungan kepercayaan.
Topologi jaringan dan strategi pemilihan UNL sangat memengaruhi sifat sistem konsensus. Topologi sangat terpusat, ketika semua node memasukkan validator yang sama dalam UNL mereka, memaksimalkan safety tetapi dapat mengurangi liveness jika validator tersebut tidak tersedia. Sebaliknya, topologi sangat terdesentralisasi dengan tumpang tindih UNL minimal dapat meningkatkan liveness namun berisiko menyebabkan kegagalan konsensus jika tumpang tindih menjadi terlalu jarang. Menemukan keseimbangan optimal membutuhkan pertimbangan cermat terhadap skenario deployment spesifik dan toleransi risiko.
Pekerjaan mendatang dapat mengeksplorasi algoritma pemilihan UNL adaptif yang otomatis mempertahankan persyaratan tumpang tindih sambil memaksimalkan desentralisasi, mekanisme agar node menyesuaikan UNL secara dinamis berdasarkan perilaku validator yang diamati, dan ekstensi algoritma konsensus yang dapat mentoleransi persentase node Byzantine lebih tinggi. Peningkatan ini dapat semakin memperkuat ketangguhan dan penerapan RPCA untuk sistem pembayaran terdistribusi berskala besar.
Conclusion
Алгоритм консенсуса протокола Ripple представляет собой значительное достижение в области распределенного консенсуса для платежных систем. Используя коллективно доверенные подсети вместо требования глобального согласия между всеми узлами, RPCA достигает консенсуса за считанные секунды, сохраняя при этом надежные гарантии против византийских отказов. Формальный анализ демонстрирует, что при условии выбора UNL с достаточным пересечением и нахождении византийских узлов ниже порогового значения сеть достигнет корректного консенсуса без форков.
Практические последствия этой работы выходят за рамки платежной сети Ripple. RPCA демонстрирует, что традиционный компромисс между задержкой консенсуса и гарантиями безопасности может быть преодолен посредством тщательного проектирования протокола и использования локальных доверительных отношений. Этот подход может оказаться применимым к другим распределенным системам, где критически важна низкая задержка и участники имеют существующие доверительные отношения, таким как системы межбанковских расчетов, отслеживание цепочек поставок и другие приложения финансовой инфраструктуры.
Развертывание RPCA в производственных системах подтвердило характеристики производительности и надежность алгоритма. Сеть Ripple обрабатывает тысячи транзакций в секунду со стабильной задержкой консенсуса 3-5 секунд, демонстрируя, что теоретические свойства эффективно переносятся на реальную эксплуатацию. По мере дальнейшего развития сети и включения дополнительных валидаторов от разнообразных операторов она служит практическим примером того, как децентрализованная система консенсуса может поддерживать как безопасность, так и производительность в масштабе.
Conclusion
Ripple Protocol Consensus Algorithm merupakan kemajuan penting dalam konsensus terdistribusi untuk sistem pembayaran. Dengan memanfaatkan subjaringan yang dipercaya secara kolektif alih-alih menuntut kesepakatan global dari semua node, RPCA mencapai konsensus dalam hitungan detik sambil mempertahankan jaminan kuat terhadap kegagalan Byzantine. Analisis formal menunjukkan bahwa selama UNL dipilih dengan tumpang tindih yang cukup dan node Byzantine tetap di bawah ambang, jaringan akan mencapai konsensus yang benar tanpa fork.
Implikasi praktis karya ini melampaui jaringan pembayaran Ripple. RPCA menunjukkan bahwa trade-off tradisional antara latensi konsensus dan jaminan keamanan dapat diatasi melalui desain protokol yang cermat serta penggunaan relasi kepercayaan lokal. Pendekatan ini berpotensi diterapkan pada sistem terdistribusi lain yang membutuhkan latensi rendah dan memiliki peserta dengan relasi kepercayaan yang sudah ada, seperti penyelesaian antarbank, pelacakan rantai pasok, dan aplikasi infrastruktur keuangan lainnya.
Penerapan RPCA di sistem produksi telah memvalidasi karakteristik kinerja dan ketangguhan algoritma ini. Jaringan Ripple memproses ribuan transaksi per detik dengan latensi konsensus konsisten 3-5 detik, menunjukkan bahwa properti teoritisnya efektif diterjemahkan ke operasi dunia nyata. Seiring jaringan terus berkembang dan menambah validator dari operator yang beragam, RPCA menjadi contoh praktis bagaimana sistem konsensus terdesentralisasi dapat mempertahankan keamanan dan performa pada skala besar.
References
Lamport, L., Shostak, R., and Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Эта основополагающая статья формализовала проблему достижения консенсуса в распределенных системах с неисправными компонентами и заложила теоретическую основу для византийски отказоустойчивых систем.
Castro, M., and Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Эта работа представила PBFT, продемонстрировав, что византийская отказоустойчивость может быть достигнута с практической производительностью, хотя со сложностью коммуникации O(n^2), ограничивающей масштабируемость.
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Эта белая книга представила консенсус на основе доказательства работы как решение проблемы двойного расходования в цифровой валюте, обеспечив децентрализованный консенсус без доверенных сторон ценой высокой задержки и потребления энергии.
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Эта статья представила алгоритм Paxos, который достигает консенсуса в асинхронных системах при отказах по сбою, повлияв на последующие разработки протоколов консенсуса.
Fischer, M. J., Lynch, N. A., and Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. Результат невозможности FLP установил фундаментальные пределы того, чего алгоритмы консенсуса могут достичь в асинхронных системах, определив пространство проектирования для практических протоколов консенсуса.
References
Lamport, L., Shostak, R., dan Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Makalah seminal ini memformalisasi masalah pencapaian konsensus dalam sistem terdistribusi dengan komponen yang rusak, serta meletakkan fondasi teoretis bagi sistem yang toleran terhadap kesalahan Byzantine.
Castro, M., dan Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Karya ini memperkenalkan PBFT dan menunjukkan bahwa toleransi kesalahan Byzantine dapat dicapai dengan performa praktis, walaupun kompleksitas komunikasi O(n^2) membatasi skalabilitas.
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Whitepaper ini memperkenalkan konsensus proof-of-work sebagai solusi untuk masalah double-spending pada mata uang digital, memungkinkan konsensus terdesentralisasi tanpa pihak tepercaya dengan biaya latensi tinggi dan konsumsi energi besar.
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Makalah ini memperkenalkan algoritma Paxos, yang mencapai konsensus dalam sistem asinkron di bawah kegagalan crash, dan memengaruhi desain protokol konsensus setelahnya.
Fischer, M. J., Lynch, N. A., dan Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. Hasil ketidakmungkinan FLP menetapkan batas fundamental mengenai apa yang dapat dicapai algoritma konsensus dalam sistem asinkron, sehingga membentuk ruang desain protokol konsensus praktis.
