Uma série de tabelas de banco de dados roda on-chain, mas a própria chain quase não armazena dados. Quando vi esse design pela primeira vez, achei que era preguiça; quanto mais pensei a respeito, mais me pareceu algo deliberado.
O que fica na SXT Chain são apenas os compromissos criptográficos de cada tabela, que podem ser entendidos como a impressão digital de uma tabela. Os dados de verdade ficam off-chain. A consulta e a prova ficam a cargo dos nós Prover, que, depois de consultar os dados, devolvem o resultado junto com a prova. A parte que verifica compara tudo com a impressão digital e sabe se houve alguma alteração. O detalhe essencial é que essa impressão digital pode ser atualizada: quando entram dados novos, é possível calcular uma nova impressão digital a partir da antiga e dos novos dados, sem precisar voltar e vasculhar os dados antigos. Assim, a tabela pode continuar crescendo sem que a chain fique mais pesada.
Minha avaliação: essa contenção é a parte mais inteligente do projeto e também sua maior aposta. É inteligente porque ele nem tenta competir com Ethereum e Solana na execução de propósito geral; simplesmente abre mão dessa corrida e se concentra no que mais falta aos contratos: a capacidade de fazer perguntas. A aposta é que o valor de uma chain dedicada apenas a compromissos de dados depende inteiramente de «haver quem esteja disposto a pagar continuamente por consultas verificáveis». Mesmo que uma chain de propósito geral fique parada, ela ainda pode se apoiar em outras aplicações. Aqui não há plano B: se a demanda não aparecer, será uma chain vazia muito bem-feita.
Há outro aspecto que, na minha opinião, é subestimado: os validadores precisam fazer staking de SXT e podem ser penalizados com o confisco da stake caso ajam de forma maliciosa. Isso pode acontecer se adulterarem compromissos, se os resultados das consultas não puderem ser verificados ou se responderem devagar demais. Em outras palavras, aqui a segurança não serve apenas para evitar o gasto duplo; serve para impedir que «os dados sejam alterados às escondidas». É outra concepção de segurança.
Por isso, não avalio o projeto pelo TPS. Observo apenas duas coisas: se os pedidos de consulta reais estão crescendo de forma contínua e quem, afinal, está pagando. A primeira indica a demanda; a segunda determina se essa demanda é real ou foi criada à base de subsídios.
@SpaceandTime : é possível fazer esse caminho dar certo? É nisso que está em jogo a captura de valor de $SXT . #SXT
#sxt $SXT
O que fica na SXT Chain são apenas os compromissos criptográficos de cada tabela, que podem ser entendidos como a impressão digital de uma tabela. Os dados de verdade ficam off-chain. A consulta e a prova ficam a cargo dos nós Prover, que, depois de consultar os dados, devolvem o resultado junto com a prova. A parte que verifica compara tudo com a impressão digital e sabe se houve alguma alteração. O detalhe essencial é que essa impressão digital pode ser atualizada: quando entram dados novos, é possível calcular uma nova impressão digital a partir da antiga e dos novos dados, sem precisar voltar e vasculhar os dados antigos. Assim, a tabela pode continuar crescendo sem que a chain fique mais pesada.
Minha avaliação: essa contenção é a parte mais inteligente do projeto e também sua maior aposta. É inteligente porque ele nem tenta competir com Ethereum e Solana na execução de propósito geral; simplesmente abre mão dessa corrida e se concentra no que mais falta aos contratos: a capacidade de fazer perguntas. A aposta é que o valor de uma chain dedicada apenas a compromissos de dados depende inteiramente de «haver quem esteja disposto a pagar continuamente por consultas verificáveis». Mesmo que uma chain de propósito geral fique parada, ela ainda pode se apoiar em outras aplicações. Aqui não há plano B: se a demanda não aparecer, será uma chain vazia muito bem-feita.
Há outro aspecto que, na minha opinião, é subestimado: os validadores precisam fazer staking de SXT e podem ser penalizados com o confisco da stake caso ajam de forma maliciosa. Isso pode acontecer se adulterarem compromissos, se os resultados das consultas não puderem ser verificados ou se responderem devagar demais. Em outras palavras, aqui a segurança não serve apenas para evitar o gasto duplo; serve para impedir que «os dados sejam alterados às escondidas». É outra concepção de segurança.
Por isso, não avalio o projeto pelo TPS. Observo apenas duas coisas: se os pedidos de consulta reais estão crescendo de forma contínua e quem, afinal, está pagando. A primeira indica a demanda; a segunda determina se essa demanda é real ou foi criada à base de subsídios.
@SpaceandTime : é possível fazer esse caminho dar certo? É nisso que está em jogo a captura de valor de $SXT . #SXT
#sxt $SXT