Terceira sessão, e hoje eu cheguei ao mecanismo que torna o tbv possível de qualquer forma: o procedimento de desafio baseado no BABE, porque toda a alegação sem necessidade de confiança depende disso aqui.
Primeiro, declare o problema com precisão. Seu btc está bloqueado no bitcoin. Seu empréstimo é reembolsado no ethereum. O btc agora deve ser liberado, mas o bitcoin não tem ideia de que o ethereum existe. O script do bitcoin não pode consultar outra cadeia, não pode executar um oráculo, não pode verificar uma computação arbitrária. Então como um utxo do bitcoin aprende que um evento do ethereum realmente aconteceu?
Todas as respostas anteriores para essa pergunta envolveram uma parte confiável. Um custodiante que monitora o ethereum e libera moedas. Uma federação de signatários que vota no que viu. Um contrato de ponte com operadores. Cada um reintroduz exatamente o intermediário do qual o depositante estava tentando escapar.
A resposta da Babylons: a redenção de garantias usa um procedimento de desafio que permite que o bitcoin verifique provas de eventos de redenção do ethereum usando apenas primitivas existentes do script do bitcoin. Leia com atenção: somente PRIMITIVAS EXISTENTES. Não é necessária nenhuma bifurcação do bitcoin, não há novos opcodes, não é preciso esperar que a comunidade do bitcoin aprove qualquer coisa. A maquinaria de verificação é montada inteiramente a partir de peças que o bitcoin já tem.
Por que a propriedade de não-fork importa tanto? Porque todo design de defi de btc que exige que o bitcoin mude primeiro é, na prática, vaporware: o bitcoin muda em escala de décadas. Um protocolo que funciona no bitcoin de hoje pode ser implantado; um protocolo que precisa do bitcoin de amanhã é um artigo de pesquisa.
O que ainda não estou certo é sobre as suposições de vivacidade dos procedimentos de desafio: quem envia a prova, quem pode contestá-la e o que acontece se ninguém aparecer durante a janela do desafio. É para aí que eu vou olhar em seguida, porque sistemas baseados em desafio só são tão fortes quanto o seu vigia mais preguiçoso.
@BabylonLabs_io #baby $BABY
Primeiro, declare o problema com precisão. Seu btc está bloqueado no bitcoin. Seu empréstimo é reembolsado no ethereum. O btc agora deve ser liberado, mas o bitcoin não tem ideia de que o ethereum existe. O script do bitcoin não pode consultar outra cadeia, não pode executar um oráculo, não pode verificar uma computação arbitrária. Então como um utxo do bitcoin aprende que um evento do ethereum realmente aconteceu?
Todas as respostas anteriores para essa pergunta envolveram uma parte confiável. Um custodiante que monitora o ethereum e libera moedas. Uma federação de signatários que vota no que viu. Um contrato de ponte com operadores. Cada um reintroduz exatamente o intermediário do qual o depositante estava tentando escapar.
A resposta da Babylons: a redenção de garantias usa um procedimento de desafio que permite que o bitcoin verifique provas de eventos de redenção do ethereum usando apenas primitivas existentes do script do bitcoin. Leia com atenção: somente PRIMITIVAS EXISTENTES. Não é necessária nenhuma bifurcação do bitcoin, não há novos opcodes, não é preciso esperar que a comunidade do bitcoin aprove qualquer coisa. A maquinaria de verificação é montada inteiramente a partir de peças que o bitcoin já tem.
Por que a propriedade de não-fork importa tanto? Porque todo design de defi de btc que exige que o bitcoin mude primeiro é, na prática, vaporware: o bitcoin muda em escala de décadas. Um protocolo que funciona no bitcoin de hoje pode ser implantado; um protocolo que precisa do bitcoin de amanhã é um artigo de pesquisa.
O que ainda não estou certo é sobre as suposições de vivacidade dos procedimentos de desafio: quem envia a prova, quem pode contestá-la e o que acontece se ninguém aparecer durante a janela do desafio. É para aí que eu vou olhar em seguida, porque sistemas baseados em desafio só são tão fortes quanto o seu vigia mais preguiçoso.
@BabylonLabs_io #baby $BABY