Eu costumava trabalhar meio período em um restaurante durante a universidade. A cozinha ficava atrás de uma parede. Os clientes conseguiam ver o menu, fazer pedidos e receber a comida. Eles não conseguiam ver como era preparada, nem quais equipamentos eram usados, nem qual fornecedor entregava os ingredientes naquela manhã. A sala de jantar e a cozinha eram dois espaços completamente separados. Se a cozinha pegasse fogo, a sala de jantar não saberia até que alguém saísse e dissesse algo. E se a sala de jantar estivesse cheia de barulho, a cozinha não se importava: eles apenas continuavam cozinhando.
Essa separação é exatamente o que a maioria das blockchains monolíticas não tem. No Ethereum, execução, armazenamento de dados e liquidação acontecem na mesma camada. Se o processamento das transações fica mais lento, a liquidação também fica mais lenta. Se o armazenamento de dados enche, a execução sofre. Tudo fica em um único cômodo.
@Dusk_Foundation separa isso com DuskDS, uma camada dedicada de Dados e Liquidação que opera independentemente do ambiente de execução. Pense nisso como construir a cozinha e a sala de jantar como estruturas separadas, com uma janela de passagem controlada. A camada de execução lida com a lógica de contratos inteligentes. O DuskDS lida com onde os dados ficam e como a finalidade é alcançada. Uma pode ser atualizada ou otimizada sem atrapalhar a outra.
Autocrítica: a separação de camadas parece bem limpa em diagramas de arquitetura. Na prática, a "janela de passagem" entre execução e liquidação introduz sua própria complexidade. Se as duas camadas processam em velocidades diferentes, surge uma questão de sincronização: o que acontece com um contrato inteligente que lê dados de liquidação que está um bloco atrás do estado da execução? A analogia do restaurante se sustenta até você perceber que, às vezes, a cozinha precisa saber quantos assentos estão ocupados em tempo real, e uma parede torna isso mais difícil, não mais fácil.
$DUSK deve ser avaliado com base em como suas camadas separadas sincronizam o estado de forma mais ou menos fluida sob carga, e não apenas em como essa separação arquitetural parece limpa no papel.
$HEMI $H #dusk
Essa separação é exatamente o que a maioria das blockchains monolíticas não tem. No Ethereum, execução, armazenamento de dados e liquidação acontecem na mesma camada. Se o processamento das transações fica mais lento, a liquidação também fica mais lenta. Se o armazenamento de dados enche, a execução sofre. Tudo fica em um único cômodo.
@Dusk_Foundation separa isso com DuskDS, uma camada dedicada de Dados e Liquidação que opera independentemente do ambiente de execução. Pense nisso como construir a cozinha e a sala de jantar como estruturas separadas, com uma janela de passagem controlada. A camada de execução lida com a lógica de contratos inteligentes. O DuskDS lida com onde os dados ficam e como a finalidade é alcançada. Uma pode ser atualizada ou otimizada sem atrapalhar a outra.
Autocrítica: a separação de camadas parece bem limpa em diagramas de arquitetura. Na prática, a "janela de passagem" entre execução e liquidação introduz sua própria complexidade. Se as duas camadas processam em velocidades diferentes, surge uma questão de sincronização: o que acontece com um contrato inteligente que lê dados de liquidação que está um bloco atrás do estado da execução? A analogia do restaurante se sustenta até você perceber que, às vezes, a cozinha precisa saber quantos assentos estão ocupados em tempo real, e uma parede torna isso mais difícil, não mais fácil.
$DUSK deve ser avaliado com base em como suas camadas separadas sincronizam o estado de forma mais ou menos fluida sob carga, e não apenas em como essa separação arquitetural parece limpa no papel.
$HEMI $H #dusk