NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressButlletins informatius
Subscriu-te al nostre butlletí.
Correu electrònic
Respectem la vostra privadesa
IniciBlogEmpresa Blockchain
Consens d’escala per a empreses: explicació de l’algorisme IBFT
Com la tolerància a fallades bizantines d’Istanbul (IBFT) millora la finalitat i augmenta el rendiment a les xarxes privades d’Ethereum. Per ConsenSys 22 de juny de 2018 Publicat el 22 de juny de 2018
Els algoritmes de consens són una de les innovacions bàsiques de la cadena de blocs, però també una de les més confuses. Satoshi Nakamoto va crear una versió de Prova de treball (PoW) que es va implementar com a mitjà per assegurar i validar simultàniament les transaccions de Bitcoin. La comunitat blockchain s’ha basat en aquesta visió bàsica per crear una sopa d’alfabet de Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant) i molts altres que estan dissenyats per generar consens en una distribució distribuïda. sistema, creant l’única font de veritat que fa que el blockchain sigui tan valuós.
IBFT (Istanbul Byzantine Fault Tolerant) és un mecanisme de consens que és una alternativa a la prova de treball en una xarxa Ethereum. Igual que altres algoritmes, IBFT garanteix una comanda única i acordada per a les transaccions a la cadena de blocs i proporciona avantatges addicionals per a les empreses, inclosa la finalitat de la liquidació. IBFT ho era implementat per primera vegada a Geth per Amis Technologies, i poc després implementat a Quorum.
Abans d’entrar en funcionament del mecanisme de consens IBFT, val la pena esmentar quan i per què es vol utilitzar IBFT. En una cadena de blocs pública, és probable que la resposta curta no ho faci. Però quan es tracta de consorci o cadenes de blocs privades, IBFT comença a semblar força atractiva.
L’algorisme PoW és famós, tant en maquinari com en electricitat. Aquest cost és intencionat per evitar que algú pugui fer-se càrrec de la xarxa fàcilment i, per tant, PoW és molt adequat per a situacions amb una descentralització completa on qualsevol persona (inclosos els atacants) pot participar. No obstant això, els nodes del consorci / cadenes privades que utilitzen les empreses són intrínsecament més fiables que els d’una cadena pública. Com a tal, el mecanisme de consens PoW pot ser massa pesat i altres mecanismes poden proporcionar confiança “suficient” per executar un sistema distribuït.
La prova de participació, de la mateixa manera, pot ser menys rellevant per a les empreses, ja que pagar el gas és menys important en una xarxa autoritzada. Com que els nodes no necessàriament necessiten mantenir la moneda a la xarxa, PoS introduiria requisits aliens.
Tenint en compte aquests compromisos, la prova d’autoritat (PoA) sorgeix com la millor solució possible, mitjançant un sistema pel qual s’assigna als nodes de la xarxa el privilegi de produir nous blocs per a la cadena mitjançant un sistema round-robin o un altre sistema arbitrari..
IBFT és un dels molts sabors de PoA i ofereix els següents avantatges:
- Finalitat immediata del bloc. Només hi ha 1 bloc proposat a una alçada determinada de la cadena. La cadena única elimina així la forquilla, els blocs dels oncles i el risc que es pugui “desfer” una transacció una vegada a la cadena en un moment posterior.
- Temps reduït entre blocs. L’esforç necessari per construir i validar blocs es redueix significativament (en particular pel que fa a PoW), augmentant considerablement el rendiment de la cadena.
- Alta integritat de dades i tolerància a fallades. IBFT utilitza un grup de validadors per garantir la integritat de cada bloc que es proposa. Es requereix una super majoria (~ 66%) d’aquests validadors per signar el bloc abans d’inserir-lo a la cadena, cosa que dificulta molt la falsificació de blocs. El “lideratge” del grup també gira amb el pas del temps, garantint que un node defectuós no pugui exercir una influència a llarg termini sobre la cadena.
- Operativament flexible. El grup de validadors es pot modificar a temps, garantint que el grup només conté nodes de confiança completa.
Aquí oferim una visió general d’IBFT, en termes no gaire tècnics. Per a algunes de les propostes originals d’IBFT, podeu revisar els EIP a GitHub:
- Documentació IBFT: https://github.com/ethereum/EIPs/issues/650
- Codi utilitzat al quòrum: https://github.com/jpmorganchase/quorum
Durant la resta d’aquest article, explorarem les consideracions més tècniques d’IBFT, discutint molts dels conceptes que es troben als EIP i que hem après a través de la nostra pròpia investigació..
Nota: El codi IBFT també es pot trobar a la sol·licitud d’extracció de go-ethereum # 16385.
Operació
El mecanisme de consens IBFT comprèn els components següents:
- A PBFT model de consens de grup inspirat.
- Un procés mitjançant el qual els membres es poden afegir / eliminar del grup de validació.
IBFT requereix que la capçalera del bloc es torni a treballar (subtilment) per donar suport a totes les facetes de la capacitat.
Model de consens de grup
Visió general
IBFT utilitza un conjunt de nodes de validació (validadors) que operen en una xarxa Ethereum per determinar si un bloc proposat és adequat per afegir-se a la cadena.
Un node dels validadors és seleccionat arbitràriament com a proposador i és responsable de construir un bloc a l’interval de blocs i compartir aquest bloc amb el grup. Si una gran majoria dels validadors consideren que el bloc és vàlid, s’afegeix a la cadena de blocs.
En finalitzar la ronda de consens, els validadors poden seleccionar un nou proposador que serà el responsable de proporcionar el bloc candidat al següent interval de blocs..
El mecanisme de consens és una màquina d’estats sincronitzats que s’encarrega de garantir que tots els validadors afegeixin el mateix bloc a la cadena a la mateixa alçada.
Si no es pot inserir un bloc, es canvia el Proposador i el procés comença de nou.
Per garantir que només es pugui afegir un bloc a la màquina estatal, IBFT impedeix canviar el bloc proposat una vegada que la super majoria dels validadors han acceptat la seva inserció (però no han realitzat aquest treball), aquest procés es denomina “Bloqueig de blocs”.
El mecanisme de consens IBFT ofereix estabilitat del sistema sempre que menys d’un terç dels nodes de validació es comportin incorrectament (ja sigui per estar compromès o per un codi defectuós). És a dir, per tolerar F nodes defectuosos, el grup de validació ha de contenir com a mínim 3F + 1 nodes (més que això no augmenta la integritat del sistema).
Nota: Aquí F implica el nombre de nodes defectuosos tolerats pel sistema.
State Machine
Estats
- Proposta en espera. El validador espera que el nou proposador actual subministri un nou bloc. Si el validador és el proposador d’aquesta ronda, prepara el bloc proposat i el transmet en un missatge de preparació prèvia.
- Preparant. Ha rebut un bloc (vàlid) proposat i ha notificat els validadors-parells; ara espera que els validadors informin la seva acceptació del bloc.
- Llestos. Ha rebut l’acceptació del bloc per part dels validadors i està esperant que estiguin en una posició similar. En aquesta etapa, el bloc proposat ha estat “bloquejat” i no es pot substituir fins que no s’hagi realitzat un intent d’inserció.
- Canvi rodó. La ronda es va esgotar el temps abans que s’arribés al consens o que no es pogués inserir el bloc. Espereu que tots els validadors estiguin d’acord sobre el número següent de la ronda.
Transicions
- AProposta en espera → Preparació. En rebre un nou bloc (missatge Prepara) del proposador (és a dir, el bloc és vàlid en el seu contingut, així com el punt d’inserció de cadena proposat).
- Proposta pendent → Canvi de ronda. La proposta rebuda no era un bloc vàlid segons un determinat conjunt de regles (p. Ex., Proposador no vàlid, numeració de ronda incorrecta).
- Preparant → Llest. Quan es reben notificacions 2F + 1 (Prepara el missatge) dels validadors que indiquen que el bloc proposat és adequat per a la inserció.
- Llest → S’està esperant la proposta. Quan es reben les notificacions 2F + 1 (missatge de confirmació) dels validadors que indiquen que estan preparats per afegir el bloc a la cadena. En la transició, es realitza el procés d’afegir el bloc a la cadena (èxit).
- A punt → Canvi de ronda. Segons Ready->En espera de la proposta, però, la inserció del bloc ha fallat.
- Canvi de ronda → S’està esperant la proposta. 2F + 1 dels validadors accepten el número següent de la ronda que s’utilitzarà.
Nota: Totes les transicions a “RoundChange” donen lloc al validador que transmet un missatge “RoundChange” als seus companys de validació..
Bloqueig de blocs
IBFT exigeix que no es creïn forquilles. Amb aquesta finalitat, un cop s’ha acordat un bloc per majoria (és a dir, en accedir a l’estat Llest) es converteix en “bloquejat”.
Això significa que no es consideraran altres blocs per a la inserció fins que no s’hagi intentat afegir aquest bloc a la cadena. Així, o bé el bloc s’insereix amb èxit (un cop rebuts suficients missatges de confirmació, ja sigui en aquesta o en les rondes posteriors), o bé es descarta el bloqueig d’inserció, i es proposa un bloc nou a l’alçada actual de la cadena.
Membres del grup de validació
Els membres del grup de validació poden canviar amb el pas del temps mitjançant un mecanisme de votació. Els membres es poden afegir o eliminar amb la majoria de vots (pis (N / 2) + 1); cada vot es capta a la capçalera del bloc.
Cada node de la xarxa (inclosos els nodes no validadors) és responsable de fer un seguiment del recompte de vots de cada validador per determinar els validadors actuals i assegurar-se que les signatures dels blocs minats caiguin dins del grup esperat..
Atès que cada vot es troba a la capçalera del bloc, només el Proponent per a una ronda determinada pot votar. Per tant, és important que els nodes s’afegeixin o s’eliminin de manera oportuna, que la funció de Proponent s’actualitzi periòdicament..
Un cop un node assoleix la majoria de vots, s’uneixen immediatament al grup de validació o en surten.
IBFT reconeix una època de votació, que defineix un punt en què se suprimeixen tots els vots que encara no han assolit la majoria, cosa que obliga a reiniciar el compte de vots. Això implica quan es compten vots, els validadors només han de començar a l’època més recent. Per defecte, l’època de votació es produeix cada 30.000 blocs.
Els vots defineixen un canvi d’estat (és a dir, es voten els candidats, es voten els validadors), no votar per un node determinat implica que el validador no vol que el node canviï d’estat (no es requereix un vot explícit per mantenir l’status quo).
Refactor de capçalera de bloc
Per donar suport a IBFT a Ethereum, cal fer una sèrie de canvis a les capçaleres del bloc. Aquests canvis inclouen:
- beneficiari: identifica el node per al qual s’està votant.
- nonce: especifica la “direcció” del vot: AUTH o DROP.
- mixHash: número màgic fixat, que identifica aquest bloc com a validat per IBFT.
- ommersHash: ha de ser el hash d’un conjunt buit, ja que no hi ha blocs ommer quan es treballa amb IBFT.
- marca de temps: ha de ser com a mínim la marca de temps del bloc pare + interval de bloc.
- dificultat: s’ha d’omplir amb 0x0000000000000001.
- extraData: conté dades específiques de l’IBFT, incloses Llista d’adreces de validació, ProposerSeal (identifica el proposant), CommittingSeals (llista dels validadors que van informar de “commit” d’aquest bloc).
Com que la llista de CommittingSeals per a cada validador és (potencialment) diferent, és important que el hash de bloc no inclogui aquesta informació, és a dir, tot i que dos blocs tenen camps CommittingSeals diferents, representen la mateixa informació (és a dir, les transaccions, etc. són idèntiques).
Conclusió
Per acabar, IBFT és una solució bizantina tolerant a fallades que ofereix una finalitat de transacció immediata que redueix la infraestructura necessària que PoW exigeix.
Tot i que és improbable que s’utilitzi mai a la xarxa principal d’Ethereum (amb un conjunt d’actors participants molt més ampli i desconegut), ofereix avantatges substancials quan s’utilitza en una cadena privada on es confia i es fa responsable del grup de validadors; proporciona una solució ideal per a una cadena amb cadència fixa i una taxa de processament de transaccions previsible.
Els processos explorats en aquest article donen confiança que una xarxa que utilitza IBFT serà tolerant als nodes bizantins i es pot recuperar si es veu que aquests nodes exerceixen un control a la xarxa.
Subscriu-te al nostre butlletí per obtenir les últimes novetats, solucions empresarials, recursos per a desenvolupadors i molt més sobre Ethereum.Guia
Guia completa de xarxes empresarials Blockchain
Seminari web
Introducció a la tokenització
Seminari web
El futur de les finances: actius digitals i DeFi
Seminari web
Què és Enterprise Ethereum?
Paper blanc
Els bancs centrals i el futur dels diners
Cas pràctic