Ripple Protokolü Uzlaşma Algoritması

Abstract

Bizans Generalleri Problemi icin, ozellikle dagitik odeme sistemleri baglaminda birden fazla konsensus algoritmasi mevcut olsa da, bunlarin cogu ag icindeki tum dugumlerin senkron iletisim kurmasi gereksiniminin yol actigi yuksek gecikmeden muzdariptir. Bu calismada, daha buyuk ag icinde kolektif olarak guvenilen alt-aglari kullanarak bu gereksinimi asan yeni bir konsensus algoritmasi sunuyoruz. Sybil saldirilarini onlemek icin gereken "guven"in aslinda kuresel degil, agdaki her dugume yerel oldugunu gosteriyoruz.

Ripple Protokolu Konsensus Algoritmasi (RPCA), agin dogrulugunu ve uzlasisini korumak icin tum dugumler tarafindan birkac saniyede bir uygulanir. Konsensus saglandiginda mevcut defter "kapanmis" kabul edilir ve son-kapanmis defter olur. Bu algoritma, Bizans hatalarina karsi guclu garantileri korurken dusuk gecikmeyle konsensus saglamasi nedeniyle benzersizdir ve bu da onu gercek zamanli finansal mutabakat sistemleri icin uygun hale getirir.

Introduction

Dagitik bir odeme sistemi, hatali veya kotu niyetli aktorler bulunsa bile odemeleri dogru ve zamaninda isleyebilmek icin bir konsensus algoritmasi uygulamalidir. Bitcoin, konsensusu proof-of-work ile saglar; bu da tum dugumlerin kriptografik bulmacalari cozmek icin hesaplama kaynagi harcamasini gerektirir. Bu yaklasim guclu guvenlik garantileri sunsa da, yuksek enerji tuketimi, dusuk islem hacmi ve yuksek degerli islemlerde bir saat veya daha fazla surebilen uzun onay gecikmeleri gibi ciddi dezavantajlara sahiptir.

Ripple Protokolu Konsensus Algoritmasi, proof-of-work gerektirmeyen dagitik konsensus icin yeni bir yaklasim sunar. Bunun yerine, agdaki dugumler bir oylama sureciyle islem kumeleri uzerinde topluca anlasir ve saniyeler icinde konsensusa ulasir. Bu konsensus mekanizmasi, dusuk gecikme ve yuksek hacmin pratik kullanim icin kritik oldugu kuresel odeme agi gereksinimleri icin ozellikle tasarlanmistir.

RPCA'daki temel yenilik, agdaki tum dugumlerin birbirleriyle uzlasmasini gerektirmemesidir. Bunun yerine her dugum, gizli anlasma yapmayacagina guvendigi diger dugumlerden olusan bir Benzersiz Dugum Listesi (UNL) tutar. Dugumler tarafindan secilen UNL'ler yeterli ortusmeye sahipse ve dugumlerin belirli bir esik oranindan azi hataliysa ag konsensusa ulasir. Bu yaklasim, odeme sistemi icin gerekli guvenligi saglarken konsensus gecikmesini dakika veya saatlerden saniyelere indirir.

Definition of Consensus

Dagitik sistemlerde konsensus, hatali veya kotu niyetli katilimcilar bulunsa bile bir dugum aginin ortak bir durum uzerinde uzlasmasi surecidir. Bir konsensus algoritmasi uc temel ozelligi saglamalidir: dogruluk (iki dogru dugum farkli karar vermez), uzlasi (tum dogru dugumler ayni karara varir) ve sonlanma (tum dogru dugumler eninde sonunda karar verir). Bu ozellikler, dagitik sistemin tek ve guvenilir bir dugummus gibi davranmasini saglar.

Konsensusun zor olmasinin nedeni dagitik sistemlerin dogasindaki guvenilmezliktir. Dugumler cokebilir, mesajlar gecikebilir veya kaybolabilir ve Bizans dugumleri keyfi ya da kotu niyetli davranabilir. Lamport, Shostak ve Pease tarafindan formellestirilen Bizans Generalleri Problemi bu zorlugu yakalar: Bazi surecler hataliyken ve iletisim guvenilmezken bir grup surec nasil uzlasabilir?

Dagitik hesaplamadaki klasik sonuclar, konsensus algoritmalarinin neleri basarabilecegine dair temel sinirlari ortaya koyar. FLP imkansizlik sonucu, tek bir dugumun bile hata verebildigi asenkron bir sistemde hicbir deterministik algoritmanin konsensusu garanti edemeyecegini gosterir. Bu nedenle pratik konsensus algoritmalari guvenlik (asla yanlis konsensusa ulasmama) ile canlilik (surekli ilerleme) arasinda denge kurar. Bitcoin'in proof-of-work'u guvenligi canliliga gore onceliklendirirken, RPCA gercekci hata varsayimlari altinda guclu guvenligi koruyup sinirli surede turleri tamamlayarak odeme sistemleri icin daha uygun bir denge saglar.

Existing Consensus Algorithms

Dagitik sistemlerde Bizans Generalleri Problemi'ni cozumlemek icin cesitli konsensus algoritmalari onerilmistir. Castro ve Liskov tarafindan tanitilan Practical Byzantine Fault Tolerance (PBFT) algoritmasi, 3f+1 dugumden olusan bir sistemde en fazla f adet Bizans hatasini tolere edebilir. PBFT, tum dugumler arasinda birden fazla mesajlasma turu ile konsensus saglar ve iletisim karmasikligi O(n^2)'dir; burada n dugum sayisidir. PBFT, kucuk aglarda guclu guvenlik ve nispeten dusuk gecikme sunsa da, ikinci dereceden mesajlasma maliyeti nedeniyle buyuk aglara iyi olceklenmez.

Lamport tarafindan gelistirilen Paxos ve turevleri, asenkron sistemlerde konsensus saglar ancak Bizans hatalari yerine cokme hatalarini varsayar. Paxos, onericilerin deger onerdigi ve kabul edicilerin oy verdigi turlar araciligiyla ilerler. Paxos keyfi mesaj gecikmelerine ve surec cokmelerine dayanikli olsa da, Bizans hatalarini ele almak icin dikkatli muhendislik gerektirir ve bazi senaryolarda livelock yasayabilir.

Bitcoin'in proof-of-work konsensusu ise Bizans saldirilarini ekonomik olarak yapilamaz hale getiren farkli bir yaklasim izler. Dugumler kriptografik bulmacalari cozmek icin yarisir ve kazanan bir sonraki islem blogunu onerir. Bu yaklasim keyfi ag buyukluklerine olceklenebilse ve Bizans hatalarina dayanikli olsa da buyuk dezavantajlari vardir: cok yuksek enerji tuketimi (Bitcoin agi icin yilda 150 milyon dolar uzeri tahminler), uzun onay gecikmeleri (yuksek degerli islemlerde siklikla 40-60 dakika) ve sinirli hacim (yaklasik saniyede 7 islem). Bu sinirlar, hizli mutabakat ve yuksek hacim gerektiren odeme uygulamalarinda proof-of-work'u elverissiz kilar.

Ripple Protocol Consensus Algorithm

Ripple Protokolu Konsensus Algoritmasi (RPCA), her sunucunun gordugu ve henuz uygulanmamis tum gecerli islemleri aday islem olarak almasiyla baslar. Sunucular daha sonra, mevcut deftere uygulanacak islem kumesi uzerinde uzlasiya varmak icin yinelemeli bir cok-turlu protokol izler. Her turda sunucular, bir sonraki deftere dahil edilmesi gerektigini dusundukleri islemlerden olusan oneriler sunar.

Her konsensus turunda sunucular, onerilerini kendi Benzersiz Dugum Listesi (UNL) icindeki diger sunuculara iletir. Ardindan sunucular, hangi islemlerin onerilerin belirli bir esik yuzdesinde yer aldigini hesaplar. Baslangicta bu esik %50'dir; yani bir islemin bir sonraki turda degerlendirilmesi icin sunucunun UNL'inin en az yarisindan gelen onerilerde gorunmesi gerekir. Konsensus ard arda turlarla ilerledikce bu esik kademeli olarak artar (genellikle %60, %70 ve son olarak %80).

Bir islem, bir sunucunun UNL'inde %80 super-cogunluk destegine ulasinca, o sunucunun nihai tur onerisine dahil edilir. Ag genelinde bu esige ulasan tum islemler deftere uygulanir; sonra defter kriptografik olarak hash'lenir ve imzalanir. Bu yeni dogrulanmis defter son-kapanmis defter olur ve surec bir sonraki aday islem kumesiyle yeniden baslar.

Konsensus sureci genellikle 5 saniye veya daha kisa surer ve islemlerin cogu super-cogunluk esigine ulasmak icin yalnizca tek tur gerektirir. Bir turda konsensusa ulasamayan islemler sonraki turlar icin aday kalir. Bu tasarim, guvenilen dogrulayicilardan super-cogunluk destegi olmayan hicbir islem deftere uygulanamadigi icin guclu guvenligi korurken agin surekli ilerlemesini saglar.

Formal Analysis of Convergence

RPCA'nin dogrulugu, agdaki farkli dugumlerin sectigi UNL'ler arasindaki ortusmeye kritik bicimde baglidir. UNL_i, i dugumunun benzersiz dugum listesi olsun; UNL_i ∩ UNL_j ise hem UNL_i hem UNL_j icinde bulunan dugumleri gostersin. Agin konsensusu koruyabilmesi icin, herhangi iki i ve j dugumu arasinda bu kesisimin, UNL'lerden buyuk olana gore yeterince buyuk olmasi gerekir.

Ozellikle protokol, tum i ve j dugum ciftleri icin |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 oldugunda guvenligi garanti eder. Bu kosul, Bizans dugumleri agin farkli kisimlarini farkli kararlar almaya zorlamaya calissa bile, guvenilen dugumlerdeki ortusmenin bir catallanmayi engellemesini saglar. Bu kosul saglanir ve herhangi bir UNL'deki Bizans dugum orani 1/5'in altinda kalirsa, tum dogru dugumler ayni konsensus kararina ulasir.

Formal ispat, iki dugum farkli konsensus kararina ulasabiliyorsa, bir dugumun son defterinde olan ancak digerinde olmayan bir T islemi bulunmasi gerektigini gosterir. Bunun olmasi icin T'nin birinci dugumun UNL'inde %80 destek alip ikinci dugumun UNL'inde %80'in altinda kalmasi gerekir. Ancak ortusme kosulu ve Bizans siniri altinda bunun imkansiz oldugu gosterilebilir: T, UNL_i'de %80 destek aliyorsa, ortusme kosulunu saglayan UNL_j'de en az %60 destek almak zorundadir; yeterli sayida tur sonunda ya %80'e yakinsar ya da her iki dugum tarafindan reddedilir.

Canlilik ozelligi, yani konsensusun sonunda mutlaka saglanmasi, dahil etme esiginin turlar boyunca deterministik bicimde artmasindan gelir. Bizans dugumleri ve ag gecikmeleri olsa bile protokol, durust dugumlerin super-cogunlugunca desteklenen islemlerin sonunda dahil edilmesini, boyle bir destegi olmayan islemlerin ise dislanmasini saglar. Konsensus icin sinirli sure (tipik olarak 5 saniye) odeme sistemi uygulamalari icin pratik canlilik garantisi sunar.

Unique Node Lists

Benzersiz Dugum Listesi (UNL), RPCA'yi diger konsensus algoritmalarindan ayiran temel bilesendir. Ripple agindaki her dugum, agi dolandirmak icin isbirligi yapmayacagina guvendigi diger dugumlerden olusan bir UNL tutar. Kritik nokta su: bu guven kuresel degil yereldir. Farkli dugumler farkli UNL'lere sahip olabilir ve tum agin uzlastigi tek bir dogrulayici kumesi zorunlu degildir. Bu tasarim, agin merkeziyetsizligi koruyarak organik bicimde olceklenmesini saglar.

UNL, proof-of-work gerektirmeden Sybil saldirilarina karsi bir onleme mekanizmasi gorevi gorur. Saf bir oylama sisteminde saldirgan, etkisini artirmak icin cok sayida sahte kimlik olusturabilir. RPCA'da ise her dugum hangi dugumlere guvendigini acikca sectigi icin, yeni kimlikler ancak mevcut dugumleri UNL'lerine eklenmeye ikna ederse avantaj saglar. Boylece Sybil direnci, hesaplama maliyetinden itibar ve guven iliskilerine kaymis olur.

Agin dogru calismasi icin UNL'ler formal analizde belirtilen sekilde yeterli ortusmeyle secilmelidir. Pratikte bu, her operator UNL seciminde ozerk olsa da kendi listesinin agin diger kisimlarinca da guvenilen dogrulayicilari icermesi gerektigi anlamina gelir. Ripple, farkli kurumlarca isletilen dogrulayicilardan olusan varsayilan bir UNL sunar; ancak operatorler kendi guven degerlendirmelerine gore bu listeyi degistirebilir.

UNL mekanizmasi ayni zamanda asamali merkeziyetsizlesmeye dogal bir yol acan bir yapi sunar. Agin erken donemlerinde daha merkezi bir dogrulayici kumesi istikrar ve guvenilirlik icin uygun olabilir. Ag olgunlastikca ve daha cesitli operatorler guvenilirliklerini kanitladikca, UNL'ler daha genis bir dogrulayici kumesini kapsayacak bicimde evrilir; boylece guvenlikten odun vermeden dayaniklilik ve merkeziyetsizlik artar.

Simulation Code

RPCA'nin teorik analizini dogrulamak ve farkli kosullardaki performansini degerlendirmek icin, ozel gelistirilmis simulasyon yazilimi ile kapsamli simulasyonlar yapildi. Simulasyon cercevesi, her biri kendi UNL'ini tutan ve konsensus protokolune katilan dugumlerden olusan bir agi modeller. Kod, islem onerisi, artan esikli oylama turlari ve defter dogrulama dahil RPCA algoritmasinin tam uygulamasini icerir.

Simulasyonlarda degistirilen temel parametreler sunlardir: ag buyuklugu (10 ila 1.000 dugum), Bizans dugum orani (%0 ila %20), UNL boyutu (tipik olarak 5 ila 50 dugum) ve ag topolojisi konfigürasyonlari. Her parametre kombinasyonu icin, sonuclarin istatistiksel gecerliligini saglamak amaciyla farkli rastgele tohumlarla birden fazla calistirma yapildi. Simulasyonlar; konsensus gecikmesi, catallanma olasiligi ve islem hacmi gibi metrikleri izledi.

Simulasyon sonuclari, yakinama ve guvenlikle ilgili teorik ongoruleri dogruladi. UNL ortusme kosulunun saglandigi ve her UNL'deki Bizans dugum oraninin %20'nin altinda oldugu tum konfigürasyonlarda ag catallanma olmadan basariyla konsensusa ulasti. Konsensus gecikmesi, ag buyuklugunden bagimsiz bicimde surekli dusuk kaldi (tipik olarak 3-5 simulasyon saniyesi) ve bu da algoritmanin olceklenebilirligini gosterdi. Konsensusu bozmak icin aktif saldiri yapan %15 Bizans dugumu olsa bile, UNL ortusme kosulu saglandigi surece dogruluk korundu.

Ek simulasyonlar; ag bolunmeleri, UNL bilesiminde ani degisiklikler ve Bizans dugumlerinin koordineli saldirilari gibi uc durumlari ve hata senaryolarini inceledi. Bu calismalar protokolun dayanikliligi hakkinda icgoru sagladi ve UNL secimi ile ag isletimi icin onerilen iyi uygulamalari sekillendirdi. Bagimsiz dogrulama ve ileri arastirmalar icin tum simulasyon kodu paylasima acildi.

Discussion

Bitcoin'in proof-of-work konsensusuyla karsilastirildiginda RPCA, odeme sistemi uygulamalari icin bircok onemli avantaj sunar. En belirgini, konsensus gecikmesinin 40-60 dakikadan (yuksek degerli Bitcoin islemleri icin tipik onerilen sure) yaklasik 5 saniyeye inmesidir. Bu iyilesme, RPCA'yi POS ve anlik mutabakat gerektiren diger kullanimlar icin uygun hale getirir. Ayrica RPCA, proof-of-work'e gore cok daha az hesaplama kaynagi gerektirir ve Bitcoin madenciliginin yol actigi buyuk enerji tuketimini ortadan kaldirir.

Bununla birlikte bu avantajlar farkli guven varsayimlari getirir. Bitcoin'in guvenligi, saldirganin agin hesaplama gucunun %50'sinden fazlasini kontrol etmedigi varsayimina dayanirken, RPCA dugumlerin yeterli ortusmeye sahip UNL'ler secmesini ve bu UNL'lerdeki Bizans oraninin esigi asmamasini gerektirir. Bu da ihtiyatli guven kararlarinin bir kismini dugum operatorlerine birakir. Pratikte bu degisim, katilimci kurumlarin zaten guven iliskilerine sahip oldugu bircok odeme kullanim senaryosunda kabul edilebilir.

Ag topolojisi ve UNL secim stratejisi, konsensus sisteminin ozelliklerini guclu bicimde etkiler. Tum dugumlerin ayni dogrulayicilari UNL'lerine ekledigi yuksek merkezi topoloji guvenligi artirir; ancak bu dogrulayicilar erisilemez olursa canlilik azalabilir. Tersine, UNL ortusmesinin cok dusuk oldugu yuksek merkeziyetsiz topoloji canliligi artirabilir; fakat ortusme cok seyreklesirse konsensus basarisizligi riski dogar. En iyi denge, dagitim senaryosu ve risk toleransi birlikte degerlendirilerek bulunur.

Gelecek calismalar; merkeziyetsizligi azamiye cikarirken ortusme kosullarini otomatik koruyan uyarlanmali UNL secim algoritmalarini, dugumlerin gozlenen dogrulayici davranisina gore UNL'lerini dinamik ayarlama mekanizmalarini ve daha yuksek Bizans oranlarini tolere edebilecek konsensus genisletmelerini arastirabilir. Bu gelistirmeler RPCA'nin buyuk olcekli dagitik odeme sistemlerindeki dayanikliligini ve uygulanabilirligini daha da artirabilir.

Conclusion

Ripple Protokolu Konsensus Algoritmasi, odeme sistemleri icin dagitik konsensus alaninda onemli bir ilerlemeyi temsil eder. RPCA, tum dugumler arasinda kuresel uzlasi gerektirmek yerine kolektif olarak guvenilen alt-aglari kullanarak saniyeler icinde konsensus saglar ve Bizans hatalarina karsi guclu garantileri korur. Formal analiz, UNL'ler yeterli ortusmeyle secildiginde ve Bizans dugumleri esik altinda kaldiginda agin catallanma olmadan dogru konsensusa ulasacagini gosterir.

Bu calismanin pratik etkileri Ripple odeme aginin otesine uzanir. RPCA, konsensus gecikmesi ile guvenlik garantileri arasindaki geleneksel degis-tokusun, dikkatli protokol tasarimi ve yerel guven iliskileri sayesinde asilabilecegini ortaya koyar. Bu yaklasim; bankalararasi mutabakat, tedarik zinciri takibi ve diger finansal altyapi sistemleri gibi dusuk gecikmenin kritik oldugu ve katilimcilarin mevcut guven iliskilerine sahip bulundugu dagitik ortamlarda da uygulanabilir.

RPCA'nin uretim ortamina alinmasi, algoritmanin performans ve dayaniklilik ozelliklerini dogrulamistir. Ripple agi, tutarli 3-5 saniye konsensus gecikmesiyle saniyede binlerce islem isleyerek teorik ozelliklerin gercek dunyada da karsilik buldugunu gosterir. Ag, farkli operatorlerden daha fazla dogrulayiciyla gelismeye devam ederken, olcekte hem guvenligi hem performansi koruyabilen merkeziyetsiz konsensusun pratik bir ornegini sunar.

References

Lamport, L., Shostak, R., ve Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Bu oncu calisma, hatali bilesenler bulunan dagitik sistemlerde konsensus problemine formal bir cerceve kazandirmis ve Bizans hata toleransli sistemlerin teorik temelini atmistir.

Castro, M., ve Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Bu calisma PBFT'yi tanitmis, Bizans hata toleransinin pratik performansla saglanabilecegini gostermis, ancak O(n^2) iletisim karmasikliginin olceklenebilirligi sinirladigini da ortaya koymustur.

Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Bu whitepaper, dijital para biriminde cift-harcama sorununa cozum olarak proof-of-work konsensusunu onermis, guvenilen tarafa gerek duymadan merkeziyetsiz konsensusu mumkun kilarken bunun bedeli olarak yuksek gecikme ve enerji tuketimini getirmistir.

Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Bu makale, cokme hatalari altindaki asenkron sistemlerde konsensus saglayan Paxos algoritmasini sunmus ve sonraki konsensus protokollerini guclu bicimde etkilemistir.

Fischer, M. J., Lynch, N. A., ve Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. FLP imkansizlik sonucu, asenkron sistemlerde konsensus algoritmalarinin neyi basarabilecegine dair temel sinirlari belirleyerek pratik konsensus protokollerinin tasarim uzamini sekillendirmistir.