Ang kasalukuyang mga blockchain na nag-susukat sa mataas na throughput ng transaksyon ay maaaring sentralisado o hindi ligtas.
Para sa Massa, nagdisenyo kami ng bagong arkitektura, na tinatawag na Blockclique, na sinusukat ang throughput ng transaksyon hanggang sa 10,000 transaksyon bawat segundo, nang hindi isinasakripisyo ang desentralisasyon ni seguridad. Ang aming arkitektura ay batay sa transaction sharding in a multithreaded block graph. Sa blog post na ito ipapakilala namin ang mga pangunahing konsepto ng Blockclique. Maari mo ring galugarin ang technical paper o makipag-ugnayan sa live testnet sa massa.net/testnet. Inaasahan namin na marinig ang iyong feedback!
TL; DR
- Pinagsasama namin ang transaction sharding at isang multithreaded block graph architecture na nagpapahintulot sa parallel blocks na may katugmang mga transaksyon.
- Pinalawak namin ang Nakamoto concensus rule sa kaso ng mga parallel blocks, na nagpapahintulot sa isang ligtas at desentralisadong consensus gamit ang Proof-of-Stake.
- Ang arkitektura ng Blockclique ay maaaring hawakan ang libu libong mga transaksyon bawat segundo, katumbas ng sa mga tradisyonal na sistema ng pananalapi.
May problema tayo sa pag-iiskala
Ang kasalukuyang mga blockchain ay hindi sumusukat. Upang maging alternatibong katunggali sa mga klasikal na solusyon sa pananalapi, ang mga blockchain ay dapat na makayanan ang ilang mga transaksyon na katulad ng sa mga klasikal na sistema. Sa kasalukuyan, pinapayagan lamang ng Bitcoin ang 5 transaksyon bawat segundo (tx/s) sa buong network habang ang Ethereum ay nagbibigay daan para sa 15-20 tx/s. Ang mga bilang na ito ay ni di nga malapit sa mga klasikal na sistema ng pananalapi. Halimbawa, ang sistema ng VISA ay nagpoproseso ng 111 bilyong transaksyon noong 2017 (isang average na 3500 tx/s). Bilang isang resulta, ang mga blockchain ay madaling ma-congested at bilang ebedensya ay ang Cryptokitties hype.
Bakit Data structure at Nakamoto consensus rule?
Ang mga limitasyon ng blockchains ay nag-uugat mula sa kanilang mismong disenyo. Ang isang blockchain ay tinatawag bilang ang “best” chain ng isang block tree, kung saan ang bawat block ay tumutukoy sa isang parent block in a tree bilang karagdagan sa pagdadala ng isang hanay ng mga transaksyon.
Kapag ang isang node ay lumilikha ng isang block, isinisiwalat nito ang block sa iba pang mga nodes ng isang peer to peer network, na siya namang nagpapasa nito sa iba pang mga nodes, at iba pa hanggang sa ang karamihan ng mga nodes ay may kaalaman na sa block. Ang prosesong ito ay tumatagal ng mga/oras, lalo na kung ang mga blocks ay malaki. Sa isang partikular na sandali, maaaring malaman ng mga nodes ang iba’t-ibang mga subset ng mga nilikhang blocks. Bilang isang resulta, ang dalawang node ay maaaring mag broadcast ng dalawang blocks na may parehong parent block, kahit na sila ay tapat pa. Ito ay tinatawag na fork, at nagbibigay ito ng dalawang alternatibong chains ng mga blocks na nagmula sa parehong ancestor block.
Dahil sa propagation delays, hindi pa nakikita ng node A ang block na nilikha ng node C (blue block) at lumilikha pa ng isang block (pula) na tumutukoy sa parehong magulang (dilaw). Nagreresulta ito sa isang fork.
Dahil ang mga alternatibong chain ay maaaring maglaman ng iba’t ibang hindi tugmang hanay ng mga transaksyon, ang mga node ay kailangang sumang ayon sa isang solong karaniwang chain upang makamit ang consensus sa mga naisagawa na transaksyon. Ang isang eleganteng paraan ng pagkamit ng consensus sa isang desentralisadong network ay kilala bilang Nakamoto consensus rule. Mula sa pananaw ng isang node, ang ideya ay upang i-rate ang bawat chain ng block tree sa pamamagitan ng pagtatalaga nito ng isang scalar fitness, at upang makabuo lamang ng mga bagong block sa pamamagitan ng pagpapalawak ng chain of maximum fitness. Ang chain of maximum fitness ay ang tinatawag natin bilang ang “blockchain”: ang mga transaksyon na lumilitaw sa mga blocks ng blockchain lamang ang itinuturing na executed.
Upang maiwasan ang mga Sybil attack, ang fitness ay dapat kumatawan sa isang bagay na mahirap gawin o makuha: ang resoruce. Sa mga sistema ng Proof of Work tulad ng Bitcoin, ang fitness ng isang chain ay tinatawag bilang kabuuang computational work na isinasagawa upang lumikha ng lahat ng mga blocks nito. Sa mga sistema ng Proof-of-Stake tulad ng Tezos, ang fitness of a chain ay nauugnay sa kabuuang bilang ng mga coins na inilagay sa mga blocks ng chain. Nakamoto ay ang pinaka malawak na ginagamit na consensus rule para sa desentralisadong blockchains, gayunpaman maraming iba pang mga consensus mechanism ang ipinapatupad. Upang mas malaman pa ang consensus mechanism, inirerekumenda namin na magsimula dito o rito.
Ang Nakamoto consensus rule ay maayos na nagpapanatili ng mga node na nakatuon sa isang solong common blockchain hangga’t ang rate kung saan nagyayari ang mga fork ay nananatiling resonable. Ang isang small size block na nagkakasya sa ilang mga transaksyon, at isang low block frequency (1 MB bawat 10 minuto sa average ng Bitcoin) ay tinitiyak na ang karamihan ng mga oras, na kung saan ang isang block ay maaaring isiwalat sa buong network bago ang isa pa, ay nalikha. Kaya, ang rate ng fork ay mababa at ang consensus ay mas madali, ngunit ang average na bilang ng mga transaksyon na mapoproseso bawat segundo ay limitado.
Sagarin ang limitasyon?
Ang bilang ng tx/s ay maaaring madagdagan sa isang mababaw na paraan sa pamamagitan man ng pagtaas ng block frequency (ang rate kung saan ang mga block ay nalikha) o sa pamamagitan ng pagtaas ng block size, upang magkasya ang mas maraming transaksyon sa bawat block. Gayunpaman ito ay limitado lamang.
Kung ang block frequency ay nadagdagan nang mas marami pa (sabihin nating isang block ng 1 MB bawat segundo), may kaunting oras lamang ang mga blocks upang magpalaganap sa network bago pa ang isa pang block: ang mga nodes ay lumilikha ng maraming mga hindi tugmang blocks, na humahantong sa isang mataas na rate ng fork at kabiguan ng consensus. Kung sa halip ang block size ay nadagdagan pa masyado (sabihin nating 1 GB), ang block broadcasting ay magiging masyadong mabagal, ang fork rate ay nagiging mataas, at pati ang consensus ay bigo rin.
Ang problemang ito ay inilalarawan sa video sa ibaba, kung saan ginagaya namin ang isang network ng mga nodes na nakagawa ng mga block sa isang setting ng Proof of Work.
Ang ilang mga cryptocurrencies ay nadagdagan ang bilang ng mga transaksyon sa bawat segundo sa pamamagitan ng pagbabago ng block size o block frequency. Halimbawa, dinagdagan ng Bitcoin Cash ang block size sa bilang ng 8, na itinaas ng bilang ng mga transaksyon sa bawat segundo sa pamamagitan ng parehong factor. Gayunpaman ang bilang na ito ay nananatiling medyo mababa. Upang madagdagan nang malaki ang bilang ng mga transaksyon na naproseso ay kinakailangan pang umasa sa iba pang mga mekanismo.
Paghihigpit sa laki ng network?
Ang isang paraan ng pagbaba ng oras na kinakailangan upang ilipat ang mga blocks sa isang network ay ang limitahan ang laki ng network. Halimbawa sa EOS, 21 awtorisadong block producer lamang ang pinapayagang magproseso ng mga transaksyon, na nagbubunga ng mga 3000–4000 tx/s. Sa Ripple, ang isang solong kumpanya ang siyang nagpapasya kung sino ang maaaring maging isang validator at gumawa ng mga blocks, upang ang protocol ay maaaring maabot ang 1500 tx/s.
Gayunpaman, ang paghihigpit sa laki ng network ay hindi tugma sa ideya ng isang bukas na desentralisadong network kung saan ang anumang node ay maaaring lumahok nang walang pahintulot. Tulad ng sabi ng mga Ethereum developer, tila may isang scalability trilemma sa kasalukuyang blockchain architectures: isang tradeoff sa pagitan ng desentralisasyon, scalability at seguridad.
Ang tunay na hamon ay ang magdisenyo ng isang blockchain na may kakayahang humawak ng libu-libong mga transaksyon habang nananatiling ganap na desentralisado at ligtas, na nagpapahintulot sa libu-libong mga node na lumahok sa block production at consensus.
Pagbabago ng istraktura ng data at mga patakaran sa consensus?
Kamakailan lamang, nagkaroon ng ilang mga pagtatangka sa pag-iskala ng mga desentralisadong currencies sa pamamagitan ng mga pagbabago sa istraktura ng data at mga patakaran sa consensus. Ang pagpapatupad ng transaction sharding, na naghahati ng mga transaksyon sa maraming mga grupo (o “shards”) na maaaring hawakan nang sabay sabay, tulad ng sa Elastico o Zilliqa, ay isang palatandaan ng paglago. Gayunpaman, sa mga protocol na ito, ang mga node na nagproproseso ng iba’t-ibang shards ay kailangang regular na sumang-ayon sa isang karaniwang blockchain, na naglilimita sa mga benepisyo ng parallelism ng sharding.
Ang isa pang linya ng trabaho ay naglalayong i-extend ang block tree structure sa isang block graph structure sa pamamagitan ng pagpayag sa mga block na magkaroon ng higit sa isang magulang. Ang unang nakadirekta na acyclic block graph (block DAG) na mga istruktura ay inilarawan sa [Lewenberg, 2015], [Sompolinsky, 2015] at [Sompolinsky, 2016]. Sa mga protocol na iyon gayunpaman, ang mga transaksyon mula sa isang block ay maaaring hindi tugma sa mga transaksyon mula sa isa pang parallel block dahil ang mga transaksyon mismo ay hindi sharded. Ang isang proseso ng pagboto ay kinakailangan upang mag order ng mga transaksyon at piliin kung alin ang isasagawa.
Ang blockclique solution na ginagamit sa Massa
Ang Blockclique ay isang bagong arkitektura na pinagsasama ang transaction sharding at isang multithreaded block DAG. Nilulutas nito ang isyu ng scalability sa pamamagitan ng parallelizing the data structure at pag-adapt ng consensus rule.
Blockclique data structure at ang consensus rule
Sa arkitektura ng Blockclique, maaaring malikha ang mga block sa isang nakapirming bilang ng mga thread. Ang isang block na ginawa sa isang partikular na thread ay tumutukoy sa isang parent block sa bawat isa sa mga thread. Ang resultang istruktura ng data ay isang multithreaded directed acyclic graph of blocks (multithreaded DAG).
Samantala, maaaring subukan ng isang address na gastusin ang parehong coin nang dalawang beses sa pamamagitan ng pagsasagawa ng mga transaksyon sa dalawang parallel na thread sa parehong oras. Pinipigilan ng Blockclique ang naturang dobleng paggastos sa pamamagitan ng pagpayag sa isang ibinigay na address na gumastos ng mga coin lamang sa isang partikular na thread (defined sa first bit ng address). Ang mga block mula sa isang naibigay na thread ay naglalaman lamang ng mga transaksyon na may mga input address na kabilang sa thread na iyon. Ang prosesong ito ay kilala bilang transaction sharding. Gayunpaman, ang transaction output ay maaaring maging anumang address, kahit pa ano pa ang thread ng mga input address.
Ang kombinasyong ito ng transaction sharding at block DAG ay nagresulta ng bagong katangian: ang mga nodes ay maaaring bumuo ng mga blocks na naka-parallel kung saan ang mga naka-enclose na mga transaksyon ay pare-pareho ng pagbuo
Sa bagong istraktura ng block na ito, ang mga node ay maaari pa ring lumikha ng mga fork sa partikular na mga thread sa pamamagitan ng paglikha ng dalawang hindi tugmang block sa parehong thread na may parehong magulang din sa thread na iyon. Sa gayon ay pinalawig namin ang Nakamoto rule upang payagan ang mga node na maabot ang isang consensus tungkol sa pandaigdigang hanay ng mga tugmang blocks (na tinatawag na “clique”) of maximum fitness. Ang consensus rule na ito ay nagsisiguro na ang bawat thread ay kumikilos tulad ng isang normal na blockchain at ang mga blocks na natagpuan sa isang thread ay isinasaalang alang din ang mas naunang mga block sa iba pang mga thread, habang pinapayagan ang bahagyang desynchronizations sa pagitan ng mga thread.
Kabaligtaran sa mga nakaraang blockchain batay sa arkitektura ng DAG, ang multithreaded block DAG na may transaction sharding at isang adapted concensus rule ay nagbibigay-daan upang lubos na makinabang mula sa block parallelization at hindi na magangailangan magbigay ng mga espesyal na pribilehiyo sa ilang mga nodes.
Mga resulta ng simulasyon
Sinubukan namin ang aming mga ideya sa pamamagitan ng mga simulasyon, na in-open source namin dito. Gamit ang mga parameter ng network na katulad ng mga natagpuan sa Ethereum (average upload bandwidth ng 32 Mb/s at average latency ng 100 ms, at libu-libong mga node), ipinakita namin na sa pamamagitan ng paggamit ng 32 parallel thread at isang Proof-of-Stake Sybil-resistance mechanism, ang aming arkitektura ay maaaring makatiis hanggang sa 10,000 tx/s na may mga oras ng kumpirmasyon ng transaksyon, sa pagkakasunud sunod ng 40s!
Ang pagpapabuti na ito ay maaaring mas maunawaan sa pamamagitan ng mga sumusunod:
- sa isang standard blockchains nodes ay dapat magkaroon ng pinakabagong block upang magsimulang magtrabaho sa susunod na block (kung hindi man, sila ay lilikha ng isang fork)
- sa Blockclique, hindi kinakailangan na magkaroon ng lahat ng pinakabagong mga blocks upang gumawa ng bago. Ang mga node ay gumagawa ng mga blocks sa parallel na mga thread nang hindi humahantong sa isang fork.
- ang arkitektura ng Blockclique ay tinitiyak ang sunud-sunod na pagkakapare-pareho ng mga coin debit para sa bawat address, habang pinapayagan ang mga coin credit na bahagyang de-synchronized.
Siyempre, ang mga kinalabasan ay mas kumplikado kaysa sa mga resultang to. Naglagay kami ng malawak na hanay ng mga parameter para sa pagsubok, ipinakita kung gaano katatag ang aming arkitektura sa iba’t ibang pag-atake, at naghain ng mga suhestiyon para sa pagpapahusay sa kasalukuyang mga consensus protocol. Kung gusto mo ng karagdagang impormasyon, iminumungkahi naming basahin ang teknikal na papel!
Subukan mo!
- Live ang testnet namin! Sa test.massa.net, makikita mo ang mga nilikha na block in real time.
- Sa explorer na ito, maaari ka ring makipag ugnayan sa testnet sa pamamagitan ng paglikha ng isang wallet at pagtanggap o pagpapadala ng mga coins.
- Kung mayroon kang computer na may maaasahang internet, mangyaring magpatakbo ng isang node! Maaari mong sundin ang mga hakbang sa aming Github.
Conclusion
Ipinakita namin na posibleng malutas ang isyu ng scaling ng blockchains gamit ang transaction sharding sa isang multithreaded block graph. Ang Massa ay umaabot sa libu-libong mga transaksyon bawat segundo nang hindi isinasaalang-alang ang desentralisasyon ni ang seguridad ng blockchain. Ang isang bagay na hindi namin binanggit ay ang aming arkitektura ay katugma sa mga smart contract na maaaring ipatupad sa loob ng isang thread o iakma upang suportahan ang multithreading.
Naniniwala kami na ang Massa ay maaaring matupad ang mga pangako ng isang scalable, secure at tunay na desentralisadong blockchain. Umaasa kami na nasasabik ka rin tulad namin at gusto naming marinig ang iyong feedback! Pumunta lamang sa aming Telegram, Discord o Reddit para ibigay ang iyong mga saloobin!
Mga Kapaki-pakinabang na mga Links:
- Testnet Explorer: https://test.massa.net
- Source code and Tutorials: https://github.com/massalabs/massa
- Telegram: https://t.me/massanetwork
- Discord: https://discord.com/invite/TnsJQzXkRN
- Reddit:https://reddit.com/r/massa/
- Youtube: https://youtube.com/channel/UChVfdvYpn0eFk4B-T7TGmOg
- All releases & changelogs from all versions
