Eu costumava ler “verificação sem confiança” na página TBV da Babylon como se isso significasse que toda a cadeia de confiança havia sido removida, não apenas um elo dela.
Então eu realmente me aprofundei no que a prova cobre.
Três partes fazem isso funcionar: contratos on-chain, provas de light-client executando em ZK-SNARKs e indexadores independentes, tudo interligado para que o consenso do Bitcoin e o estado de UTXO possam ser verificados a partir de algum lugar inteiramente diferente, sem que alguém tenha que confiar em um custodiante para atestar isso.
Hmm.
Porque o SNARK prova algo mais específico do que a proposta sugere. Ele confirma que uma transição de estado do Bitcoin reivindicada corresponde às regras embutidas no circuito, o mesmo circuito que codifica a lógica de consenso do próprio Bitcoin — checagem de matemática com matemática. Ele assume duas coisas sem provar nenhuma delas: que o cabeçalho e os dados de transação enviados ao circuito eram precisos desde o início e que o próprio circuito foi construído corretamente da primeira vez.
Fechei a página e rastreei as duas suposições até onde elas realmente vivem.
A primeira é o trabalho do indexador, uma peça separada e intercambiável colocada ao lado do sistema de prova. A segunda fica com quem construiu e auditou o circuito — uma questão de confiança única, e não contínua.
Não estou dizendo que isso torne o design fraco. Todo esquema de light-client ZK construído sobre dados de uma cadeia externa tem essas “costuras” em algum lugar. A Babylon só as nomeia em vez de dobrá-las na proposta.
Se o SNARK verifica a transição de estado perfeitamente, mas qualquer suposição estivesse errada, a parte “sem confiança” realmente se sustentou, ou apenas a parte que nunca foi sem confiança em primeiro lugar?
#baby
$BABY
@BabylonLabs_io
$BABY
#baby
Então eu realmente me aprofundei no que a prova cobre.
Três partes fazem isso funcionar: contratos on-chain, provas de light-client executando em ZK-SNARKs e indexadores independentes, tudo interligado para que o consenso do Bitcoin e o estado de UTXO possam ser verificados a partir de algum lugar inteiramente diferente, sem que alguém tenha que confiar em um custodiante para atestar isso.
Hmm.
Porque o SNARK prova algo mais específico do que a proposta sugere. Ele confirma que uma transição de estado do Bitcoin reivindicada corresponde às regras embutidas no circuito, o mesmo circuito que codifica a lógica de consenso do próprio Bitcoin — checagem de matemática com matemática. Ele assume duas coisas sem provar nenhuma delas: que o cabeçalho e os dados de transação enviados ao circuito eram precisos desde o início e que o próprio circuito foi construído corretamente da primeira vez.
Fechei a página e rastreei as duas suposições até onde elas realmente vivem.
A primeira é o trabalho do indexador, uma peça separada e intercambiável colocada ao lado do sistema de prova. A segunda fica com quem construiu e auditou o circuito — uma questão de confiança única, e não contínua.
Não estou dizendo que isso torne o design fraco. Todo esquema de light-client ZK construído sobre dados de uma cadeia externa tem essas “costuras” em algum lugar. A Babylon só as nomeia em vez de dobrá-las na proposta.
Se o SNARK verifica a transição de estado perfeitamente, mas qualquer suposição estivesse errada, a parte “sem confiança” realmente se sustentou, ou apenas a parte que nunca foi sem confiança em primeiro lugar?
#baby
$BABY
@BabylonLabs_io
$BABY
#baby