Redes permisionadas — Análisis transacciones por segundo

Redes permisionadas — Análisis transacciones por segundo

Tags
Blockchain
Published
diciembre 26, 2018
Una Blockchain permisionada es un ecosistema cerrado donde cada participante está definido. Este tipo de Blockchain nos permite crear organizaciones o consorcios de organizaciones para intercambiar eficientemente información y un historial de transacciones.
En esta ocasión se estará analizando la cantidad de transacciones por segundo que puede ejecutar diferentes clientes de la red de Ethereum con diferentes algoritmos de consenso.
notion image
 
Debido a que los sistemas distribuidos actúan de manera independiente cuando procesan información (ejecutan transacciones) actualizan el estado, debe haber un acuerdo no discutible en los estados resultante entre los nodos. El proceso para lograr el acuerdo entre los estados de los nodos distribuidos se llama “Consenso

Prueba de Autoridad (PoA por Proof of Authority)

Son una familia de algoritmos de consenso para redes permisionadas cuya importancia se debe a los aumentos de rendimientos con respecto a los algoritmos BFT clásicos; esto es debido a que los mensajes intercambiados son más ligeros. PoA fue originalmente descrito como parte del ecosistema de Ethereum para redes privadas y la implementación en sus clientes Geth (Clique)y Parity (Aura).
Estos algoritmos se basan en un conjunto nodos confiables N llamados autoridades. Cada autoridad está identificada con un id único y la mayoría de ellas se asume como honestos, es decir al menos N/2 +1.Las autoridades llegan a un consenso para ordenar las transacciones realizadas por los clientes. Estos algoritmos se basan en un esquema de rotación, un enfoque ampliamente utilizado para distribuir de manera justa la responsabilidad de crear nuevos bloques entre las autoridades.
Las implementaciones de los algoritmos Clique y Aura trabajan de manera diferente, aun cuando los dos tiene una primera ronda donde un nuevo bloque es propuesto por el líder actual, Aura requiere de una ronda más de aceptación de un nuevo bloque, mientras que Clique no.
Diferencias entre Aura y Clique
Diferencias entre Aura y Clique
 

Clique

Clique es un algoritmo implementado en Geth, el cliente de Ethereum escrito en Golang. Este algoritmo se desarrolla en épocas que se identifican mediante una secuencia prefijada en los bloques que han sido aceptados.
Un ejemplo de un bloque en Clique sería:
>eth.getBlock(8);{ difficulty: '2',extraData: '0xd88301080a846765746888676f312e31302e32856c696e7578000000000000002dc51ef1f370d69954631ff07eaee75c1a01ebf2d87c6d8f88bdc709da1375425057e66ff6502110085c9d67b24d131709549451bea56889bb3fbd20611524bc01',gasLimit: 7500000,gasUsed: 0,hash: '0x55e7750bc3ee8762fe02602ab95dc510326eb2d1481e75e448823d582e949b7d',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0x0000000000000000000000000000000000000000',mixHash: '0x0000000000000000000000000000000000000000000000000000000000000000',nonce: '0x0000000000000000',number: 8,parentHash: '0x303edf0cfcb3f236c700b353c40a203c542214efbbd58b4eca454d8c6e39e415',receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',size: 606,stateRoot: '0x32064cb7f950941bc90d4180086dfb3c80cd85735fba994283bc0443a76aa4ac',timestamp: 1540831630,totalDifficulty: '17',transactions: [],transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',uncles: [] }
En nuestras pruebas internas hemos logrado obtener las siguientes estadísticas sobre la cantidad de transacciones por segundo que se pueden lograr, las pruebas se realizaron con 4 nodos validadores y 2 nodos clientes.
Para poder simular un comportamiento real de la red, se desarrolló un pequeño software que pudiera crear una cantidad específica de hilo y enviando transacciones a los 2 nodos clientes, dado como resultado un máximo de 134 transacciones por segundo al tener al menos 7 hilos concurrentes realizando operaciones.
Transacciones por segundo con Clique utilizando múltiples hilos
Transacciones por segundo con Clique utilizando múltiples hilos
 

Aura

Aura (autoridad de ronda) es un algoritmo implementado en Parity, el cliente de Ethereum escrito en RUST. En este algoritmo se supone que la red es síncrona y que todas las autoridades se sincronizan dentro del mismo tiempo UNIX t.
Un ejemplo de un bloque en Aura sería:
> eth.getBlock(64);{ author: '0xad385c92a482c4926e650aa355ba66dc504f9f6f',difficulty: '340282366920938463463374607431768211446',extraData: '0xde830202008f5061726974792d457468657265756d86312e32382e30826c69',gasLimit: 9393937,gasUsed: 0,hash: '0x1915f964f61d9bd2debeec22c805ea4b5c8471b4453b65fa16d29ed14bd0c09e',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0xAd385c92a482C4926E650Aa355Ba66Dc504f9F6f',number: 64,parentHash: '0xb57b358a24ac7f87c0e2f5698755c2a961d2fa3f273b79325b58bfa4106b3122',receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',sealFields:[ '0x845bd789c1','0xb8417415941a5671767ad29c67ea6d6464a743d9f6a79f0cdc009fb17d1503b2c2a50dfef77d5fdb966cbabb2fe2016fd49972fbc925bc9a218dc4ac9a31056c878f00' ],sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',signature: '7415941a5671767ad29c67ea6d6464a743d9f6a79f0cdc009fb17d1503b2c2a50dfef77d5fdb966cbabb2fe2016fd49972fbc925bc9a218dc4ac9a31056c878f00',size: 585,stateRoot: '0x877eb4dadd1eaf4dabd8ec51ebeff13dc3ca5338d91b8770ad67694fc4f6aae2',step: '1540852161',timestamp: 1540852161,totalDifficulty: '21778071482940061661655974875631624812031',transactions: [],transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',uncles: [] }
En nuestras pruebas internas hemos logrado obtener las siguientes estadísticas sobre la cantidad de transacciones por segundo que se pueden lograr, las pruebas se realizaron con 4 nodos validadores y 2 nodos clientes.
Para poder simular un comportamiento real de la red, se desarrolló un pequeño software que pudiera crear una cantidad específica de hilo y enviando transacciones a los 2 nodos clientes, dado como resultado un máximo de 37 transacciones por segundo al tener al menos 10 hilos concurrentes realizando operaciones.
Transacciones por segundo con Aura utilizando múltiples hilos
Transacciones por segundo con Aura utilizando múltiples hilos
 

Tolerancia a la falta Bizantina de Estambul (Istanbul Byzantine Fault Tolerance (IBFT))

IBFT un algoritmo implementado en Quorum, es una modificación del algoritmo práctico de tolerancia de faltas bizantinas. En IBFT cada bloque requiere múltiples rondas de votación por parte del conjunto de validadores para llegar a un acuerdo mutuo, que se registra como una colección de firmas en el contenido del bloque. Un validador nunca asume que el “proponente del bloque” sea correcto y honesto. En su lugar verifica el bloque propuesto al igual que otros algoritmos de consenso que operan en un entorno no confiable.
 
Un ejemplo de un bloque en IBFT sería:
>quroum.getBlock(4043570);{ difficulty: '0x1',extraData: '0xd783010702846765746887676f312e392e35856c696e75780000000000000000f90179f869940211711f81d923f5e7f6037a48569951457aacbf9460749d2abbd6217521f02e3a786431be632303d094976c9455ad158eeb07b5599f7d9cbfd4ef4f80ca94b87dc349944cc47474775dde627a8a171fc9453294cd2de20ccf75025402ccab76f67c6b1556fe754ab84156e581e2c053d23be58a3734250ce37a48315978e3856e3a6f7a27f0f0a83469714681de57019f19785439d7523fbdbecfee5fdcb273f342648bb0e36c829f9800f8c9b8418205272aacde8061efe06a1d960a7a95c0eae87b7c69b9edce92928dc34938a80106fc8252cc356ce98e07acbaa72bfa7879b4c61dbeae45dd9b0f2aa206cfc800b8416c69045e237f83fd21215d66f13c215d3fa552819216cfa4d95960637ea9ac58665472be3f2a43c7279150357ab4c72bf4af85f6dea6eb7ba261609025f09a6701b841a1501c37163a894fe0fbb99921021cc5a1e3b60ae0f03f33ecce13b80a249df2055951758b149d3a32d2481c081f493574a53c79155158d78e7dd35e7728cda800',gasLimit: '0xffffffffffffffff',gasUsed: '0x0',hash: '0xc8e94b4ddd0a17ee5a053478b1837dc6a2f19e124d6e6c3601967e2ccf0792d7',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0x0000000000000000000000000000000000000000',mixHash: '0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365',nonce: '0x0000000000000000',number: '0x3db332',parentHash: '0x38d931d074689613e39fe5d3f6a388d0c5ef9a5ec09a86a3cb13f05d4a3f567a',receiptsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',size: '0x3a2',stateRoot: '0xf7f86b47e3e0b2e790a0f60039ec2b2af66d311aab6c9343d93040b4599878cc',timestamp: '0x5bd87a6b',totalDifficulty: '0x3db333',transactions: [],transactionsRoot: '0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421',uncles: [] }
En nuestras pruebas internas hemos logrado obtener las siguientes estadísticas sobre la cantidad de transacciones por segundo que se pueden lograr, las pruebas se realizaron con 4 nodos validadores y 2 nodos clientes.
Para poder simular un comportamiento real de la red, se desarrolló un pequeño software que pudiera crear una cantidad específica de hilo y enviando transacciones a los 2 nodos clientes, dado como resultado un máximo de 281 transacciones por segundo y un promedio de 200 al tener al menos 10 hilos concurrentes realizando operaciones.
Transacciones por segundo con IBFT utilizando múltiples hilos
Transacciones por segundo con IBFT utilizando múltiples hilos
 

Raft

Raft es un algoritmo implementado en Quorum, es un algoritmo conocido de consenso desarrollado por investigadores de la Universidad de Stanford, este algoritmo ha sido implementado en diferentes frameworks de computación distribuida como Kubernetes, Docker Swarm, etc.
Raft a diferencia de BFT supone que el líder siempre actúa honestamente, todos los seguidores replican ciegamente los bloques propuestos por el líder sin hacer preguntas. Si el nodo líder desaparece, la red elegirá automáticamente uno nuevo después de un periodo de tiempo establecido y seguirá funcionando.
Un ejemplo de un bloque en Raft sería:
> quorum_raft.getBlock(7); { difficulty: '0x20000',extraData: '0x',gasLimit: '0xdf9e16e9',gasUsed: '0x5208',hash: '0x908f41b9d76cd097299163a674d03bc87c35662d1c1c68a4c9c00214bea6efca',logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',miner: '0x0000000000000000000000000000000000000000',mixHash: '0x0000000000000000000000000000000000000000000000000000000000000000',nonce: '0x0000000000000000',number: '0x7',parentHash: '0x943c3406c5c48a8d34321ba17d95959c64e8b87bf404c09c0f59dfde10aee482',receiptsRoot: '0x056b23fbba480696b65fe5a59b8f2148a1299103c4f57df839233af2cf4ca2d2',sha3Uncles: '0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347',size: '0x269',stateRoot: '0x79979cf33ad85dfdd6a63c3d364078b2ee95ad029c7284ca4e1a5bf17b024ee7',timestamp: '0x156047ff0485a040',totalDifficulty: '0xe0000',transactions:[ '0x984bfd066f2d7b9d2d5056477da3e0213d99904930db1484e0c5bd9eea3d317a' ],transactionsRoot: '0x85abd103660f4b2634a1c9d7657ef2ba4e2c41012c74cdc2bbfa43485c2babea',uncles: [] }BlockInfo {Block: '0x7',Block_Tx: 1,LastBlock: 1,TPS_Last_TwoBlock: 1,TPS_Media: 0.6666666666666666,TotalTransactions: 2 }
En nuestras pruebas internas hemos logrado obtener las siguientes estadísticas sobre la cantidad de transacciones por segundo que se pueden lograr.
Para poder simular un comportamiento real de la red, se desarrolló un pequeño software que pudiera crear una cantidad específica de hilo y enviando transacciones a los 2 nodos clientes, dado como resultado un máximo de 141 transacciones por segundo al tener al menos 10 hilos concurrentes realizando operaciones.
notion image
Transacciones por segundo con Raft utilizando múltiples hilos

Conclusiones

Luego de realizar el estudio de los clientes y algoritmos de consenso mas utilizados para crear redes permisionadas en Ethereum, se puede concluir que el ganador en cuanto a las transacciones por segundo que puede emitir es Quorum con el algoritmo de consenso IBFT, sin embargo, este proyecto recibe pocas actualizaciones y la lista de problemas de su cliente cada dia aumenta.
 
Referencias
  1. Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance.
  1. Stefano De Angelis, Leonardo Aniello. PBFT vs Proof-of-Authority: Applying the CAP Theorem to Permissioned Blockchain.
  1. BitFury Group and J. Garzik. Public versus private blockchains.
  1. Aura. https://github.com/paritytech/parity/wiki/Aura.
  1. Clique. https://github.com/ethereum/EIPs/issues/225.
  1. Raft. https://raft.github.io/
  1. IBFT. https://github.com/ethereum/EIPs/issues/650