Ebolusyon ng Kadena, ang Unang Tunay na Pribadong Blockchain

Si George Samman ay isang blockchain at Cryptocurrency consultant at advisor na kamakailan ay nag-co-author ng isang mahalagang ulat sa arkitektura ng blockchain kasama ang KPMG.

Dito, ipinaliwanag ni Samman kung paano ang consensus algorithm na nakamit ng Raft ay sa wakas ay naayos ng malayong kamag-anak nito, Kadena.

Sinasaklaw ng artikulong ito ang blockchain ng Kadena. Gumagamit ito ng ScalableBFT upang mag-alok ng mataas na pagganap (8,000-12,000 na mga transaksyon sa bawat segundo) na may ganap na pagtitiklop at pamamahagi sa mga dating imposibleng sukat (ang kapasidad para sa higit sa 500 kalahok na mga node).

Ito, kasama ang multi-layered na modelo ng seguridad at incremental na hashing ay nagbibigay-daan para sa isang tunay na matatag na blockchain. Batay sa Raft at Juno, nag-embed ang Kadena ng buong smart contract language (Pact) sa blockchain nito na maaaring patakbuhin bilang pampubliko (plain text) o pribado (double-ratchet encrypted) na mga transaksyon.

Ito ay isang malaking hakbang pasulong sa blockchain space, posibleng kumakatawan sa isang bagong henerasyon ng blockchain Technology sa pamamagitan ng pagpapakilala nito ng ideya ng "pervasive determinism".

Katulad ng Bitcoin, ang blockchain ng Kadena ay mahigpit na isinama, at ang pag-unawa sa kung ano ang kaya nito, at kung ano ang ipinahihiwatig ng mga kakayahan na ito, ay nangangailangan ng pagsakop ng malaking halaga ng lupa. Dahil dito, hinati ko ang artikulo sa tatlong bahagi: 1) Panimula at Balsa, 2) Mga Nauna kay Kadena – Tangaroa at Juno, at 3) Kadena's Blockchain - ScalableBFT, Pact at Pervasive Determinism.

Bahagi 1: Panimula at ang Algorithm ng Pinagkasunduan ng Balsa

Ang kasaysayan sa likod ng Kadena ay isang kawili-wiling case study sa bagong larangan ng blockchain consensus algorithm at distributed computing.

Kadena ay isang 'malayong kamag-anak' ng Algoritmo ng pinagkasunduan ng balsa. Ang mekanismo ng pinagkasunduan ng Raft ay sinundan ng Tangaroa (isang Byzantine Fault Tolerant (BFT) Raft) at ang proyekto ng JP Morgan Juno (isang tinidor ng Tangaroa), alinman sa mga ito ay mas matagal sa ilalim ng aktibong pag-unlad.

Ang bagong blockchain Quorum ni JP Morgan

ay ibang-iba sa Juno at gumagamit ng fusion ng mga ideya mula sa sidechains at Ethereum – pinapayagan ang mga pampublikong smart contract sa blockchain bilang karagdagan sa mga pribadong kontrata, na kinakatawan bilang mga naka-encrypt na hash at ginagaya sa pamamagitan ng mga side-channel.

Si Kadena ang "next generation Juno". Gumagamit ito ng bago, ngunit nauugnay, protocol na tinatawag na ScalableBFT na na-spawned mula sa open-source code ng proyektong Juno at binuo ng dalawang pangunahing developer na nagtayo ng Juno. Bago sumisid nang malalim sa Kadena, isang maikling kasaysayan at paglalarawan ng Raft at ang mga nauna sa Kadena ay kailangang talakayin.

Pinagkasunduan sa balsa

Ang Raft consensus algorithm ay isang solong sistemang nakabatay sa lider para sa pamamahala ng isang replicated log. Gumagamit ito ng replicated na state machine architecture at gumagawa ng resultang katumbas ng Paxos, ngunit naiiba ang istruktura.

Ang pagpapanatiling pare-pareho ang replicated log ay ang trabaho ng consensus algorithm. Sa modelong ito, ginagawa ng pinuno ang karamihan sa trabaho dahil inilalabas nito ang lahat ng mga update sa log, pagpapatunay ng mga transaksyon, at sa pangkalahatan ay pinamamahalaan ang cluster. Ginagarantiyahan ng raft consensus ang mahigpit na pag-order at pagtitiklop ng mga mensahe. Wala itong pakialam kung ano ang nilalaman ng mga mensahe.

Ang isang bagong pinuno ay inihalal gamit ang mga randomized na timeout, na nati-trigger kung ang isang tagasunod ay hindi nakatanggap ng komunikasyon mula sa pinuno bago ang pag-timeout ay gumana. Ang mga ito ay tinatawag na "heartbeats".

Kung ang tagasunod ay walang natatanggap na komunikasyon sa panahong ito, ito ay magiging isang kandidato at magsisimula ng isang halalan. Ang isang kandidato na tumatanggap ng mga boto mula sa karamihan ng buong cluster (mga node sa network) ang magiging bagong pinuno. Karaniwang kumikilos ang mga pinuno hanggang sa mabigo sila. Ang mga tibok ng puso ay ipinadala upang matiyak na naroon pa rin ang pinuno; kung walang matatanggap ay bagong halalan ang magaganap.

Ang mga sumusunod na yugto ay kung paano nagkakaroon ng consensus ang Raft:

• Nagsisimula ang isang kumpol ng mga server ng Raft node sa bawat paglulunsad ng node bilang isang "Follower". Sa kalaunan, ang ONE node ay mag-timeout, magiging isang kandidato, makakakuha ng mayorya ng mga boto at magiging pinuno.
• Ang bawat node ay nag-iimbak ng isang log na naglalaman ng mga utos. Trabaho ng Pinuno na tanggapin ang mga bagong utos, mahigpit na iutos ang mga utos sa log nito, kopyahin ang log nito sa mga tagasunod nito, at sa wakas ay ipaalam sa mga tagasunod kung kailan gagawin ang mga log na kanilang kinopya. Sa gayon, tinitiyak ng consensus algorithm na ang mga log ng bawat server ay pareho ang pagkakasunud-sunod.
• Ang mga log ay "nakatuon" kapag sila ay ginagaya sa karamihan ng mga node. Kinokolekta ng pinuno ang bilang ng replikasyon at, kapag nakita ang karamihan, gumawa ng sarili nitong mga bagong entry sa log at ipinapaalam sa mga tagasunod nito na gawin din ito.
• Sa "commit" ang utos sa bawat log entry ay sinusuri ng isang makina ng Estado. Dahil ang Raft ay walang malasakit sa katawan ng utos, ang anumang makina ng estado ay maaaring magproseso ng mga nakatuong entry. Bukod dito, tinitiyak ng pinagkasunduan na ang pagpapatupad ng utos ay palaging nagaganap sa parehong pagkakasunud-sunod na ang mga utos ay nagmumula sa Log na mahigpit na iniutos.
• Ang mga makina ng estado ay mananatiling pare-pareho hangga't ang mga pagpapatupad ng command ay deterministiko.
• Kapag nagpadala ang isang kliyente ng utos sa ONE sa mga server, ipapasa ng server na iyon ang utos sa pinuno o ang pinuno. Kinokolekta ng pinuno ang bagong utos, itinalaga ito ng Log Index, inilalagay ito sa isang Log Entry, at idinaragdag ang utos sa hindi nakatalagang bahagi ng log nito.
• Sa tuwing ang pinuno ay may hindi nakatalagang mga entry, kinokopya nito ang bahaging ito ng log sa mga tagasunod nito. Kapag sinabihan ang pinuno ng matagumpay na pagkopya ng karamihan ng cluster, gagawin nito ang mga bagong entry at inuutusan ang mga tagasunod nito na gawin din ito.
• Sa tuwing ang isang bagong log entry ay ginawa ang pinagkasunduan tungkol sa entry na ito ay naabot. Pagkatapos ay sinusuri ito ng makina ng estado sa bawat server.
• Mula sa puntong ito, tapos na ang Raft at maaaring magpasya ang mga tagapagpatupad kung paano haharapin ang mga tugon; pagtugon sa kliyente o paghihintay sa kliyente na magtanong para sa resulta.

Ang mga tugon sa kliyente ay karaniwang asynchronous.

Ang Raft consensus protocol ay ganoon lang – isang consensus algorithm. Wala itong ideya ng at, bilang default, ay ganap na bukas sa anumang client na nagbibigay ng mga utos. Ang tanging paghihigpit sa pakikilahok na ginagawa nito ay kung anong mga node ang umiiral sa isang partikular na oras.

Bukod dito, ang pinuno ay may ganap na awtoridad sa kumpol at inuutusan ang mga tagasunod na magtiklop at mangako. Hindi nito ipinapalagay ang mga pag-atake ng Byzantine, kailangan lang nitong hawakan ang mga pagkakamali sa pag-crash, dahil ang mga node ay ipinapalagay na altruistic.

Bahagi 2: Mga Nauna sa Kadena - Tangaroa at Juno

Tangaroa: Ang unang hakbang patungo sa BFT Raft

Ang Tangaroa ay Byzantine Fault Tolerant (BFT) na variant ng Raft consensus algorithm na inspirasyon ng orihinal na Raft algorithm at ng Practical Byzantine Fault Tolerance (PBFT) algorithm.

Ang Byzantine fault tolerance ay tumutukoy sa mga pagkabigo ng klase na dulot ng mga malisyosong node na umaatake sa network. Kung bumaba ang ilan sa mga node, kinakailangan para sa network na magpatuloy sa pagtakbo nang walang tigil.

Sa karaniwang Raft, kailangan mong kopyahin ang isang log entry sa karamihan ng mga node sa cluster bago ito gawin. Para sa mga algorithm ng consensus ng BFT, kabilang ang Tangaroa, ang kinakailangang laki ng cluster ay hindi bababa sa 2f + 1, kung saan ang f ay ang bilang ng mga pagkabigo na gusto mong tiisin (kabilang ang parehong mga na-crash na node at nakompromisong node). Ang pinagkasunduan ay nakakamit sa pamamagitan ng mayoryang boto ng cluster; kung f <= 3 kung gayon ang laki ng kumpol = 7 at mga non-byzantine na node = 4. Ang ilang BFT protocol ay maaaring mangailangan ng 3f+1.

Ang isang Byzantine Leader ay maaaring magpasya na arbitraryong taasan ang commit index ng iba pang mga node bago sapat na makopya ang mga log entry, kaya magdulot ng mga paglabag sa kaligtasan kapag nabigo ang mga node sa susunod. Inililipat ng Tangaroa ang commit na responsibilidad mula sa pinuno, at mapapatunayan ng bawat node para sa sarili nito na ang isang log entry ay ligtas na nakopya sa isang korum ng mga node at na ang korum na ito ay sumasang-ayon sa isang pag-order.

Binibigyang-daan ng Tangaroa ang mga kliyenteng humahadlang sa kasalukuyang pamunuan kung mabibigo itong umunlad, sa parehong paraan na pinapayagan ng ibang mga algorithm ng BFT Consensus sa kliyente na kumilos bilang isang pinagkakatiwalaang orakulo upang mapatalsik ang ilang mga node. Nagbibigay-daan ito sa Tangaroa na pigilan ang mga pinuno ng Byzantine na magutom sa sistema ngunit lubos itong nagtitiwala sa kliyente.

Pinuno ng halalan at mga yugto

Ginagamit ng Tangaroa ang Raft bilang pundasyon para sa pinagkasunduan; kaya mayroong isang pinuno. Sa Tangaroa, tulad ng sa Raft, ang bawat node ay nasa ONE sa tatlong estado: pinuno, tagasunod, o kandidato.

Katulad ng Raft, ang bawat node ay nagsisimula bilang isang tagasunod, kung saan ang ONE ay mag-timeout sa kalaunan at tatawag ng halalan. Ang nagwagi sa halalan ay nagsisilbing pinuno para sa natitirang bahagi ng termino; magtatapos ang mga termino kapag may nahalal na bagong pinuno. Minsan, ang halalan ay magreresulta sa hating boto, at ang termino ay matatapos nang walang pinuno. Sa kasong ito, muling mag-time out ang isang tagasunod (nare-reset ang mga timeout kapag naboto ang isang boto o tinawag ang isang halalan) at sisimulan muli ang proseso ng pagboto.

Upang simulan ang isang halalan, dinadagdagan ng isang tagasunod ang kasalukuyang termino nito at nagpapadala ng RequestVote (RV) Remote Procedure Call (Mga RPC) kahanay sa bawat isa sa iba pang mga node sa cluster na humihingi ng kanilang boto. Ang mga RPC na ginagamit ng Tangaroa ay katulad ng mga RPC ng Raft maliban na ang bawat RPC ay nilagdaan at na-validate sa pamamagitan ng mga lagda ng PPK.

Ang mga RPC ay nagbibigay-daan para sa isang palitan ng data sa pagitan ng iba't ibang mga computer na naninirahan sa isang network at ang mga lagda ay nagbibigay-daan para sa pagtanggap ng mga node upang i-verify kung aling node ang nagpadala ng RPC bilang karagdagan sa pagpapahintulot sa anumang node na ipasa ang anumang iba pang node ng RPC sa anumang oras.

Kapag ang isang Tangaroa node ay nakatanggap ng isang RV RPC na may wastong lagda, ito ay nagbibigay ng boto kaagad kung wala itong pinuno sa kasalukuyan (nagaganap lamang sa pagsisimula). Kung hindi, sisimulan nito ang proseso na tinatawag ng Tangaroa na "LazyVote."

Ang layunin ng LazyVote ay protektahan ang mga hindi tagasunod na Byzantine mula sa pagpili ng isang bagong pinuno kapag ang pinuno ay walang mali; nang walang tamad na pagboto, ang isang byzantine node ay maaaring magpalitaw ng paulit-ulit na halalan anumang oras at magutom ang sistema. Kapag ang isang bagong RV ay natanggap ng isang tagasunod, ito ay nagse-save ng RV at naghihintay para sa lahat ng mga sumusunod na kundisyon na matugunan:

a) Ang pag-timeout sa halalan ng tagasunod ay nag-trigger ng mga sunog bago nito mahawakan ang isang tibok ng puso mula sa kasalukuyang pinuno nito. Kung ang isang tibok ng puso ay natanggap, ang LazyVote ay na-clear.

b) Ang bagong termino ng RV ay mas malaki kaysa sa kasalukuyang termino nito.

c) Ang nagpadala ng Request ay isang karapat-dapat na kandidato (wastong pirma ng PPK at T ipinagbawal ng kliyente ang node).

d) Ang node na tumatanggap ng RV ay hindi bumoto para sa isa pang pinuno para sa iminungkahing termino.

e) Ang kandidato ay nagbabahagi ng isang log prefix sa node na naglalaman ng lahat ng nakatuon na mga entry. Palaging tinatanggihan ng isang node ang Request kung nakakatanggap pa rin ito ng mga mensahe ng heartbeat mula sa kasalukuyang pinuno, at binabalewala nito ang RequestVote RPC kung nagsimula na ang iminungkahing termino.

Kung ang isang RequestVote ay wasto at para sa isang bagong termino, at ang kandidato ay may sapat na napapanahon na log, ngunit ang tatanggap ay tumatanggap pa rin ng mga tibok ng puso mula sa kasalukuyang pinuno, irerekord nito ang boto nito nang lokal, at pagkatapos ay magpapadala ng tugon sa boto kung ang node mismo ay sumasailalim sa timeout ng halalan o marinig mula sa isang kliyente na ang kasalukuyang pinuno ay hindi tumutugon.

Sa ilalim ng tamad na pagboto, ang isang node ay hindi nagbibigay ng boto sa isang kandidato maliban kung ito ay naniniwala na ang kasalukuyang pinuno ay may mali. Pinipigilan nito ang mga node na nagsisimula sa mga hindi kinakailangang halalan mula sa pagkuha ng mga kinakailangang boto upang maging pinuno at magutom sa sistema.

Naghihintay ang mga node hanggang sa maniwala silang kailangang magkaroon ng halalan bago bumoto. Kapag naipadala na ang isang boto, ia-update ng node ang term number nito. Hindi nito ipinapalagay na ang node na binoto nito ay nanalo sa halalan gayunpaman, at tatanggihan pa rin nito ang mga AppendEntries (AE) RPC mula sa kandidato kung wala sa mga ito ang naglalaman ng isang hanay ng mga boto na nagpapatunay na nanalo ang kandidato sa halalan. Nagsisilbi ang AE sa dalawahang layunin ng mga tibok ng puso at mga carrier ng mga bagong entry sa log na nangangailangan ng pagtitiklop. Ang kandidato ay nagpapatuloy sa estado ng kandidato hanggang sa mangyari ang ONE sa tatlong bagay:

a) Nanalo ito sa halalan sa pamamagitan ng pagtanggap ng mayoryang boto mula sa cluster. Dapat i-save ng isang kandidato ang mga boto na ito – RequestVoteResponse (RVR) RPC – para sa pamamahagi sa hinaharap.

b) Ang isa pang node ay nagtatatag ng sarili bilang isang pinuno

c) Lumilipas ang isang yugto ng panahon na walang nagwagi (ibig sabihin: nakakaranas ito ng isa pang timeout ng halalan)

Ang isang kandidato na nanalo sa halalan ay nagsusulong ng sarili sa estado ng pinuno at nagpapadala ng isang AE na heartbeat na mensahe na naglalaman ng mga boto na naghalal dito at ang na-update na numero ng termino upang maitatag ang awtoridad nito at maiwasan ang mga bagong halalan. Mabisang pinipigilan ng mga nilagdaang boto ang isang byzantine node na arbitraryong isulong ang sarili bilang pinuno ng mas mataas na termino. Bukod dito, ang bawat tagasunod ay nagsasagawa ng isang muling pagbibilang sa nabanggit na boto ng mayorya, pinapatunayan at binibilang ang bawat boto na ipinadala ng bagong pinuno upang malayang i-verify ang bisa ng halalan.

Pamamahala

Tulad ng Raft, gumagamit si Tangaroa ng mga randomized na timeout para ma-trigger ang mga halalan sa lider. Ang pinuno ng bawat termino ay pana-panahong nagpapadala ng mga mensahe ng tibok ng puso (mga walang laman na AE RPC) upang mapanatili ang awtoridad nito. Kung ang isang tagasunod ay hindi nakatanggap ng komunikasyon mula sa isang pinuno sa isang random na piniling yugto ng panahon, ang oras ng halalan, pagkatapos ito ay magiging isang kandidato at magpasimula ng isang bagong halalan.

Bilang karagdagan sa mga spontaneous follower-triggered elections, pinapayagan din ng Tangaroa ang interbensyon ng kliyente: kapag ang isang kliyente ay nakakita ng walang pag-unlad kasama ang isang lider sa loob ng isang yugto ng panahon na tinatawag na progress timeout, ito ay nagbo-broadcast ng UpdateLeader RPCs sa lahat ng mga node, na nagsasabi sa kanila na huwag pansinin ang mga tibok ng puso sa hinaharap mula sa kung ano ang pinaniniwalaan ng kliyente bilang kasalukuyang pinuno sa kasalukuyang termino. Babalewalain ng mga tagasunod na ito ang mga mensaheng tumitibok ng puso sa kasalukuyang termino at time out na parang nabigo ang kasalukuyang pinuno, na nagsimula ng bagong halalan.

Natanggap na data

Ang data (mga bagong command) ay nagmula sa mga kliyente ng Raft cluster, na nagpapadala ng mga kahilingan sa pinuno. Ginagaya ng pinuno ang mga kahilingang ito sa cluster, at tutugon sa kliyente kapag naabot ang isang korum sa cluster sa Request iyon.

Ang bumubuo sa isang "Request" ay nakadepende sa sistema. Nakadepende sa system kung paano iniimbak ang data. Mahalaga para sa estado na magpatuloy sa disk, upang ang mga node ay mabawi at matandaan ang impormasyon na kanilang ginawa (kung aling mga node ang kanilang binoto, kung anong mga log entry ang kanilang ginawa, ETC). Kung wala ito, hindi gagana ang protocol.

Idinagdag ni Tangaroa ang BFT sa ebolusyon ng Raft

Juno

Ang proyekto ng JP Morgan na Juno ay bahagi ng Tangoroa at naging patunay ng konsepto na nagawang palakihin ang Tangaroa upang magsama ng hanggang 50 node at pataasin ang bilis ng transaksyon hanggang sa 5,000 transaksyon bawat segundo.

Nakita ng JPM team sa likod ni Juno ang potensyal na kinakatawan ng mala-Tangaroa approach – isang high performance na pribadong blockchain. Inulit nila ang ideya sa loob ng isang taon at open sourced ang proyekto noong Pebrero 2016. Nagdagdag sila ng matalinong wika ng kontrata, nag-ayos ng ilang pagkakamali sa disenyo at nagtagumpay sa pagkamit ng 10x na pagtaas ng performance na nagbigay-daan sa pagbabago ng bilang ng mga node na bumoto habang tumatakbo ang system. Pinahintulutan ni Juno ang pagdaragdag at pag-alis ng mga node, at ito ay isang pinahintulutang distributed system kung saan kilala ang lahat ng node sa network.

Ang mga yugto ng mekanismo at proseso ng halalan ng pinuno ay kapareho ng Tangaroa (tingnan sa itaas). Katulad nito, ang isang transaksyon ay itinuturing na live kapag ito ay ganap na ginagaya at nakatuon sa log.

Ang pinuno ang magpapasya sa pagkakasunud-sunod ng mga utos at ang bawat node ay nagpapatunay. Ang bawat node ay nakapag-iisa na nagpapasya kung kailan gagawa ng isang log entry batay sa ebidensya na natatanggap nito mula sa iba pang mga node. Ang bawat log entry ay indibidwal na nakatuon at incrementally hash laban sa nakaraang entry. Ito ay tumatagal ng humigit-kumulang 5ms para sa isang solong log entry upang pumunta mula sa pinuno na tumatanggap ng entry hanggang sa ganap na consensus na naabot at latency ng network.

Bahagi 3: Blockchain ng Kadena – ScalableBFT, Pact, at Pervasive Determinism

Cryptography

Iba sa Raft, ang bawat replica sa isang BFT Raft system (isang pamilya ng mga algorithm na kinabibilangan ng Tangaroa, Juno, at Kadean's ScalableBFT) ay nagko-compute ng cryptographic hash sa tuwing magdaragdag ito ng bagong entry sa log nito. Kinuwenta ang hash sa nakaraang hash at ang bagong idinagdag na log entry.

Maaaring lagdaan ng isang node ang huling hash nito upang patunayan na kinopya nito ang kabuuan ng isang log, at mabilis itong ma-verify ng ibang mga server gamit ang lagda at hash. Palaging pumipirma ang mga BFT Raft node at mga kliyente bago magpadala ng mga mensahe at tanggihan ang mga mensaheng walang wastong lagda.

Gumagamit ang BFT Rafts ng Incremental Hashing na nagbibigay-daan sa mga node upang matiyak na pareho ang mga nilalaman at pagkakasunud-sunod ng mga log ng ibang node ay tumutugma sa kanilang sarili. Gamit ang kaalamang ito, ang mga node ay maaaring independiyenteng gumawa ng mga log entry nang ligtas dahil pareho ang mga nilalaman at pagkakasunud-sunod ng mga log ng ibang node na pinatunayan sa pamamagitan ng pagtutugma ng mga incremental na hash.

Ang BFT Rafts ay gumagamit ng mga digital na lagda upang patotohanan ang mga mensahe at i-verify ang kanilang integridad. Pinipigilan nito ang isang pinuno ng Byzantine na baguhin ang mga nilalaman ng mensahe o pamemeke ng mga mensahe at pinoprotektahan ang cluster sa pangkalahatan mula sa isang malaking bilang ng mga pag-atake ng Byzantine.

Pinagkasunduan

Sa Raft, ang isang Pinuno ay inihalal sa pamamagitan ng mga randomized na timeout na mag-trigger sa isang Tagasunod na magmungkahi ng sarili bilang Kandidato at Request ng mga boto. Ginagawa rin ito ng ScalableBFT, ngunit sa isang cryptographically secured na paraan. Halimbawa, kung ang isang Pinuno ay hindi maabot, ang isang timeout ay magti-trigger ng isang bagong halalan ngunit ang proseso ng halalan ay matatag laban sa mga Byzantine node na nagdedeklara ng mga halalan. Inaayos ng ScalableBFT ang mga isyung naranasan nina Juno at Tangaroa tungkol sa tamad na pagboto.

Ang tanging natatanging kakayahan ng Leader ay: 1) pag-order ng mga bagong transaksyon bago ang pagkopya at 2) pagkopya ng mga bagong transaksyon sa mga Follower node. Mula sa puntong iyon, ang lahat ng mga node ay nakapag-iisa na nagpapatunay sa parehong consensus validity at indibidwal na integridad ng transaksyon.

Ang pag-alis ng hindi nakikilalang paglahok ay isang kinakailangan sa disenyo para sa mga pribadong blockchain, at ito ay nagpapahintulot para sa isang mataas na pagganap na mekanismo ng BFT Consensus upang palitan ang pagmimina. Ang pangunahing karagdagan ng ScalableBFT sa pamilya ng BFT Rafts ay ang kakayahang mag-scale sa 1000's ng mga node nang hindi binabawasan ang throughput ng system.

Ang bawat transaksyon ay ginagaya sa bawat node. Kapag ang karamihan ng mga node ay kinopya ang transaksyon, ang transaksyon ay gagawin. Ang mga node ay nangongolekta at namamahagi ng impormasyon (incremental na hash) tungkol sa kung ano ang kanilang kinopya at ginagamit ang impormasyong ito upang independiyenteng magpasya kung kailan magko-commit (>50% ng iba pang mga node ay nagpapadala sa kanila ng mga incremental na hash para sa mga hindi naka-commit na transaksyon na kanilang sinasang-ayunan).

Ito ay karaniwang gumagana sa pamamagitan ng paggawa ng mayoryang boto sa kung ano ang gagawin. Ang paggawa ng isang transaksyon ay T nangangahulugan na ito ay isasagawa, kundi ito ay permanenteng ginagaya ng karamihan ng cluster. Ang mga masasamang transaksyon, ang mga nagkakamali o may masamang mga lagda, ay ginagaya at ang trabaho ng pinagkasunduan ay ang magbigay ng perpektong nakaayos na pagtitiklop.

Ang paggawa ng isang transaksyon ay nagbibigay-daan sa bawat node na independiyenteng suriin (i-parse/decrypt/validate ang Crypto/execute/ ETC…) bawat transaksyon sa magkatulad na paraan. Ang bawat transaksyon ay ipinares sa isang output, maaari itong mula sa "masamang Crypto" hanggang sa output ng layer ng matalinong kontrata (na maaari ding maging isang error).

Sa wakas, bukod sa pinuno na kinokopya ang mga bagong transaksyon sa bawat node, ang mga node ay higit pa o hindi gaanong independyente. Sa halip na "pag-sync," ibino-broadcast nila ang "Nag-replicate ako hanggang sa mag-log index N at mayroon itong incremental na hash ng H" sa cluster at kinokolekta ang impormasyong ito mula sa iba pang mga node – batay sa mga resulta mula sa iba pang mga node, ang bawat node ay maaaring independiyenteng magpasya kung ang cluster ay na-replicate na lampas sa bar na kailangang i-commit (isang mayorya na replikasyon para sa ilan mula sa hindi pa nakasaad na log index N).

Narito ang banayad na bahagi: ang incremental na hash ay nagpapahiwatig ng pagtitiklop ng lahat ng nauna rito. Kung kinokopya ng pinuno ang 8,000 bagong transaksyon (na kung ano ang ginagawa nito sa kasalukuyan), ang bawat node ay kailangan lamang na ipamahagi at mangalap ng ebidensya para sa huling transaksyon ng batch na iyon dahil nagpapahiwatig ito ng tamang pagkopya ng mga nauna rito. Sa halip na magpadala ng 8,000 mensahe (ONE para sa bawat transaksyon) na nagpapatunay sa wastong replication node ay tinatalakay lamang ang pinakabagong transaksyon.

Ito ang dahilan kung bakit kailangan ng Kadena ng napakaraming pipelining, dahil naisip ng team kung paano gumawa ng 8,000 transaksyon sa parehong bilis ng paggawa ng isang transaksyon.

Ang ScalableBFT ay kumakatawan sa isang pambihirang tagumpay sa larangan ng BFT consensus dahil ito ang una at tanging deterministikong BFT consensus na mekanismo na maaaring sumukat sa daan-daang node na may ganap na pagtitiklop at pag-encrypt. Nagbibigay din ang ScalableBFT ng natatanging modelo ng seguridad na kilala bilang pervasive determinism na nagbibigay ng seguridad hindi lamang sa antas ng transaksyon ngunit sa antas ng pinagkasunduan pati na rin habang ini-encrypt ang bawat transaksyon gamit ang Noise Protocol (tingnan sa ibaba).

Gumagamit Kadena ng deterministic consensus

Ang mekanismo ng pinagkasunduan ay deterministiko kung ang proseso ng pinagkasunduan ay ganap na tinukoy sa protocol at ang prosesong ito ay hindi gumagamit ng randomness. Gaya ng sinabi sa itaas, ang Raft, halimbawa, ay gumagamit ng mga randomized na timeout upang mag-trigger ng mga halalan kapag bumaba ang isang pinuno (dahil ang pinuno ay T makapagsalita ng "Malapit na akong mag-crash", mayroong isang timeout na naglalakbay upang i-prompt ang isang node upang suriin kung ang pinuno ay down) ngunit ang halalan ay T bahagi ng pinagkasunduan sa antas ng transaksyon, ito ay sa halip ay isang paraan upang maghanap ng isang node sa o.

Ang ScalableBFT ay deterministiko at tumigas tulad na:

• Magko-commit lang ang mga node kapag sumang-ayon sa kanila ang karamihan ng cluster
• Ang katibayan ng kasunduan ay dapat na ganap na naa-audit anumang oras
• Kapag walang katibayan ng kasunduan, huwag gawin.

Ang Kadena ay partikular na idinisenyo para sa mga pinahihintulutang network, at dahil dito ay ipinapalagay nito na ang ilang mga pag-atake (tulad ng isang DoS) ay hindi malamang at wala sa kontrol nito. Kung mangyayari ang ONE , magla-lock ang system (lahat ng node ay mag-timeout sa kalaunan ngunit hindi magtatagumpay ang isang halalan) o uupo nang walang ginagawa.

Kapag natapos na ang naturang kaganapan, babalik ang mga node sa consensus at babalik sa normal ang mga bagay. Gayunpaman, sa isang pinahihintulutang network, ang mga administrator ay magkakaroon ng ganap na kontrol at papatayin ang koneksyon na nagdudulot ng isyu.

Ang halalan ng pinuno ay halos kapareho sa Raft dahil ang anumang node ay maaaring ihalal na pinuno, ang bawat node ay nakakakuha ng ONE boto bawat termino, at ang mga halalan ay tinatawag kapag ang randomized timeout ng ONE sa mga node ay nagpaputok (ang timer ay ni-reset tuwing may isang node na makakarinig mula sa pinuno).

Ang pinakamalaking pagkakaiba ay na sa Raft isang node na nakakakuha ng sapat na mga boto ang namumuno, samantalang sa ScalableBFT isang node na nakakakuha ng karamihan ng mga boto ay namamahagi ng mga boto na iyon sa bawat iba pang node upang ipakita (sa paraang BFT) na ito ay nahalal na pinuno ng cluster.

Inaayos ng mekanismo ng ScalableBFT ang mga isyung nakikita sa Juno at Tangaroa, tulad ng isang “runaway candidate” kung saan nag-time out ang isang non-Byzantine node dahil sa partition ng network ngunit, dahil nadagdagan ang termino nito, T ito makakabalik sa consensus at sa halip ay magpapatuloy sa pag-timeout pagkatapos ay dagdagan ang termino nito (“Runaway”.)

Ginagarantiyahan ng raft consensus ang mahigpit na pag-order at pagtitiklop ng mga mensahe; T mahalaga kung ano ang nasa bawat mensahe at maaaring mula sa mga random na numero hanggang ciphertext hanggang sa mga plain-text na smart contract. Ginagamit ng Kadena ang layer ng log bilang isang serbisyo sa pagmemensahe kapag tumatakbo sa isang naka-encrypt na konteksto; katulad ng Signal na maaaring magpatakbo ng Noise protocol encryption sa SMS. Ang ScalableBFT ay nagpapatakbo ng Noise sa isang blockchain.

Ang ScalableBFT ay nagdaragdag ng consensus robustness, na ang layer na tumatalakay sa pagbibigay-kahulugan sa mga mensahe ay ipinapalagay bilang isang garantiya, ngunit pati na rin ang mga incremental na hash na nagtitiyak ng perpektong pagkopya ng mga mensahe. Noise protocol slots sa pagitan ng consensus at smart contract execution, pag-encrypt/pagde-decrypt ng mga mensahe kung kinakailangan; dahil ang mga mensahe ay ciphertext lamang ang ilan sa mga normal na trick para sa pag-iwas sa isang Cartesian blowup ng mga live na pagsubok ay kailangan upang tumakbo sa bawat mensahe nang walang pagtagas ng impormasyon.

Modelo ng seguridad/pervasive determinism

Ginagamit Kadena ang terminong "pervasive determinism" upang ilarawan ang "ideya ng isang blockchain na gumagamit ng PPK-Sig based cryptography para sa mga garantiya ng authorship (tulad ng Bitcoin) at binubuo ng isang ganap na deterministic consensus layer bilang karagdagan sa Turing-incomplete, single-assignment smart contract layer.

Ang mga implikasyon ng isang 'pervasively deterministic' blockchain ay medyo malalim, dahil ito ay nagbibigay-daan para sa isang bitcoin-ledger na klase ng auditability na mapalawak nang malalim sa consensus layer sa pamamagitan ng pagsasama-sama ng maraming mga layer ng cryptographic trust.

Kunin bilang halimbawa ang isang transaksyon na naglo-load ng bagong module ng matalinong kontrata na tinatawag na "mga pautang." Sabihin na ang "mga pautang" ay nag-import ng isa pang module na tinatawag na "mga pagbabayad" na nasa chain na. Ang matagumpay na pag-import ng "mga pagbabayad" lamang ay nagpapahiwatig ng sumusunod (na ang bawat isa ay ganap na naa-audit sa pamamagitan ng cryptographic na paraan):

• Sino ang pumirma sa transaksyon na nag-load ng "mga pagbabayad"
• Anong mga consensus node ang nasa cluster sa oras ng paglo-load
• Anong mga consensus node ang sumang-ayon na wasto ang transaksyon
• Anong mga node ang bumoto para sa kasalukuyang pinuno sa oras ng pag-load
• Sino ang pinuno
• Sino ang dating pinuno
• ETC.

Ang isang malawak na deterministikong sistema ay nagpapahintulot sa mga bagong transaksyon na gamitin hindi lamang ang cryptographic na tiwala na natural na nangyayari habang ang mga transaksyon ay pinagsama-sama sa isang blockchain, kundi pati na rin ang tiwala kung paano pumasok ang mga transaksyong iyon sa ledge sa unang lugar. Sa paggawa nito, maaari kang lumikha ng isang system na mas secure kaysa sa Bitcoin dahil ang proseso ng pinagkasunduan ay nagiging bilang cryptographically trusted, auditable, at gusot pati na rin, na may mga pagpapatupad sa antas ng transaksyon na nagpapahiwatig na ang mga partikular na Events sa antas ng pinagkasunduan ay naganap at sa bawat implikasyon ay cryptographically verifiable.

Nagbibigay ito ng BFT hindi lamang para sa consensus layer kundi para sa transaction layer (ginagawa na rin ito ng Bitcoin ). Ito ay iba sa, halimbawa, PBFT na ipinapalagay na ang mga transaksyong ipinadala mula sa server ng kliyente ay wasto na nag-iiwan sa kanila ng kakayahang makompromiso. Bukod dito, ang mga non-Raft BFT sa pangkalahatan ay ipinagkakatiwala sa kliyente ang kakayahang mag-depose/mag-ban ng mga node. Ang Pervasive Determinism ay tumatagal ng alternatibong pananaw: huwag magtiwala, i-audit ang lahat.

Ang pagpayag sa ScalableBFT na isama ang malaganap na determinismo ay lumilikha ng isang ganap na paranoid na sistema na matatag sa bawat at bawat layer sa pamamagitan ng permanenteng seguridad (ibig sabihin: isang anyo ng cryptographic na seguridad na maaaring i-save sa disk). Mayroon itong modelo ng seguridad ng bitcoin para sa mga transaksyon, pinalawak ang modelong ito sa antas ng pinagkasunduan, at nagdaragdag ng mga matalinong kontrata nang hindi nangangailangan ng pagmimina o mga tradeoff na nakasanayan na ng karamihan sa industriya. Ito ay isang tunay na blockchain na mabilis at nasusukat.

Tinanong ko si Will Martino (co-founder ng Kadena) para sa mga detalye kung paano ito gumagana para sa bawat layer:

Ano ang iyong modelo ng seguridad sa antas ng pinagkasunduan?

Para sa pagtitiklop, gumagamit ang Kadena ng incrementally hash na log ng mga transaksyon na kaparehong ginagaya ng bawat node. Sumasang-ayon ang mga ito sa mga nilalaman ng log sa pamamagitan ng mga ipinamahagi na nilagdaang mensahe na naglalaman ng incremental na hash ng isang naibigay na index ng log, na pagkatapos ay kinokolekta ng iba pang mga node at ginagamit upang isa-isang mangatuwiran tungkol sa kung kailan kinakailangan ang isang commit. Walang mga duplicate ang pinapayagan sa log at ang mga mensahe ng pagtitiklop mula sa pinuno na naglalaman ng anumang mga duplicate ay tinatanggihan kaagad.

Gumagamit kami ng mga blake2 na hash at Term number para tukuyin ang pagiging natatangi, na nagbibigay-daan sa mga kliyente ng system na huwag mag-alala tungkol sa pagpapadala ng mga duplicate nang hindi sinasadya o tungkol sa isang malisyosong node/man-in-the-middle (MITM) na muling pagsusumite ng mga command. Gumagamit kami ng permanenteng seguridad, isang PPK-sig-based na diskarte sa pag-verify ng authorship (o anumang uri ng diskarte na maaaring i-save sa disk) na halos kapareho sa kung paano bine-verify ng Bitcoin ang mga transaksyon ngunit sa antas ng pinagkasunduan (bilang karagdagan sa antas ng transaksyon).

Salungat ito sa ephemeral security na gumagamit ng secured channels (TLS) para sa validation ng authorship – isang napakababang diskarte kung saan ang tanong na "sino ang nagpadala ng transaksyon X?" ay sinasagot hindi sa pamamagitan ng PPK cryptography ngunit sa pamamagitan ng consensus-level na query dahil ang anumang indibidwal na node ay walang kakayahang magbigay ng BFT na sagot.

Ano ang iyong modelo ng seguridad sa antas ng transaksyon?

Ang mga ideya ng panandalian at permanenteng seguridad ay sumasaklaw sa parehong consensus at antas ng transaksyon, dahil ito ay pinagkasunduan na nagbibigay ng smart contract execution layer ng mga indibidwal na transaksyon. Sa antas ng matalinong kontrata/transaksyon, gumagamit din kami ng permanenteng seguridad, na sumusuporta sa row level na pampublikong susi na awtorisasyon na native sa Pact.

Mahalaga ito dahil ang ephemeral ay nagpapahiwatig na ang isang umaatake ay ONE server ang layo mula sa pagpapanggap bilang isang entity; gumagana ang mga secure na channel sa pamamagitan ng point to point na pamamahagi ng mga bagong transaksyon ng kliyente/nagsusumite sa mga cluster node sa TLS at tinitiyak ng consensus na ang isang partikular na transaksyon ay dapat gawin at kopyahin. Gayunpaman, kung ang isang attacker ay na-hack ang client server na may hawak sa kabilang dulo ng TLS na koneksyon, maaari silang makipagtransaksyon na parang sila ang kliyente nang hindi ang cluster ang mas matalino.

Ang permanenteng seguridad, sa kabilang banda, ay may maraming susi para sa mga indibidwal na tungkulin sa isang partikular na entity kaya nangangailangan ng isang umaatake na magkaroon ng access sa mga indibidwal na susi; dagdag pa, na may permanenteng seguridad ang mga transaksyon ng CEO ay nilagdaan gamit ang ibang susi kaysa sa mga transaksyon ng Mail Clerk vs ephemeral kung saan ang "sino ang nagpapadala ng transaksyong ito" ay tinutukoy ng isang field na "mula sa: X".

Kung ang parehong koneksyon sa TLS ay ginagamit upang isumite ang parehong mga transaksyon ng CEO at Clerk, ang lohika ng awtorisasyon at awtorisasyon ay isang modelong "dahil sinabi ko/pagkatiwalaan mo ako" kumpara sa isang PPK-sig na diskarte kung saan ka nagbe-verify laban sa naaangkop na susi bago isagawa. Ang blockchain ng Kadena ay idinisenyo upang magtiwala nang kaunti hangga't maaari; kung alam namin ang isang mas paranoid o pinong diskarte kaysa sa mga row-level na PPK signature, gagamitin namin iyon sa halip.

Ano ang iyong kumpidensyal na modelo ng transaksyon?

Gumagamit kami ng Double-Ratchet protocol (kung ano ang ginagamit ng Signal, WhatsApp, ETC… para sa mga naka-encrypt na komunikasyon) na naka-embed sa blockchain (mga naka-encrypt na katawan ng transaksyon) para sa mga kaso ng paggamit na pinapanatili ng multi-party Privacy . Nakikipagtulungan kami sa paniwala ng magkahiwalay na mga database sa pamamagitan ng 'pact' na primitive sa Pact – inilalarawan nila ang isang multiphase commit workflow sa mga magkahiwalay na database sa pamamagitan ng mga naka-encrypt na mensahe.

Mga matalinong kontrata

Ang Pact ay isang buong smart-contract na wika, ang interpreter nito ay binuo sa Haskell. Sa Kadena, ang bawat transaksyon ay isang matalinong kontrata at ang wika ng Pact smart contract ay open sourced. Ang Pact ay nakatuon sa database, transactional, Turing-incomplete, single-assignment (hindi mababago ang mga variable sa kanilang buhay), at sa gayon ay lubos na pumapayag sa static na pag-verify.

Ang Pact ay binibigyang-kahulugan din - ang code na iyong isusulat ay kung ano ang nagpapatupad ng on-chain - samantalang ang Solidity ay pinagsama-sama, na nagpapahirap sa pag-verify ng code, at imposible ring itama ang mga isyu sa seguridad sa mga lumang bersyon ng wika, sa sandaling pinagsama-sama. Pact ships na may sarili nitong interpreter, ngunit maaaring tumakbo sa anumang deterministic-input blockchain, at maaaring suportahan ang iba't ibang mga backend, kabilang ang komersyal na RDBMS. Sa ScalableBFT blockchain, ito ay tumatakbo sa isang mabilis na SQLite storage layer.

Ang Kadena blockchain ay naglalaman ng lahat ng mga tampok na ito:

Sa konklusyon, ang Kadena ay nakabuo ng isang ganap na pagkopya, scalable at deterministic na consensus algorithm para sa mga pribadong blockchain na may mataas na pagganap. Ang solusyon sa blockchain na ito ay maaaring maging isang malaking hakbang para sa mga kompanya ng serbisyo sa pananalapi na naghahanap ng isang tunay na pribadong solusyon na nananatiling totoo sa marami sa mga pangunahing tampok ng Bitcoin blockchain nang walang pagmimina (patunay ng trabaho), hindi nagpapakilala at paglaban sa censorship habang nagbibigay ng mga pangunahing tampok ng disenyo na hinahangad ng mga serbisyo sa pananalapi lalo na sa scalability at pagiging kumpidensyal.

Ang artikulong ito ay nai-publish dati sa Sammantics blog at na-reproduce dito nang may pahintulot. Ilang pag-edit ang ginawa para sa istilo at kaiklian.

Larawan ng cogs sa pamamagitan ng Shutterstock