#nil $NIL @Nillion
Os Covenants da Nillion levantam uma questão interessante sobre confiança: o que determina que uma instrução privada deve ser revelada?
A Nillion descreve a sua arquitetura da seguinte forma: um Covenant sela um conteúdo até que uma condição seja satisfeita. As suas partes encriptadas são distribuídas por um comité de nós, para que nenhum operador consiga reconstruir o conteúdo original sozinho. Quando a condição é satisfeita, os nós publicam as suas partes, permitindo que o conteúdo seja reconstruído e verificado na Ethereum antes de ocorrer a ação subsequente.
A distinção fundamental está entre o mecanismo documentado — selar uma instrução até que uma condição seja satisfeita — e as garantias de segurança mais abrangentes, que dependem da implementação e das premissas do protocolo.
Consideremos uma transação condicional associada a uma fonte de preços. Se essa fonte estiver desatualizada ou for imprecisa, manter a instrução encriptada não torna os dados que desencadeiam a ação fiáveis. A confidencialidade protege a estratégia contra a exposição prematura; por si só, não garante que a condição seja avaliada corretamente. Por isso, as premissas de confiança subjacentes ao acionamento e à revelação são tão importantes quanto o mecanismo de privacidade.
A questão mais profunda é em que é que o sistema tem de confiar. Uma condição correta, uma revelação legítima e a confidencialidade são requisitos distintos. Proteger o conteúdo não prova automaticamente que o acionamento foi avaliado corretamente ou que a revelação respeitou as regras pretendidas. Essas garantias dependem do modelo de verificação do protocolo e das suas premissas.
Para que a execução condicionada se torne prática, o que merece maior escrutínio: a fiabilidade do acionamento, a integridade da revelação ou as premissas em que o protocolo se baseia para proteger ambos?
$NIL
Os Covenants da Nillion levantam uma questão interessante sobre confiança: o que determina que uma instrução privada deve ser revelada?
A Nillion descreve a sua arquitetura da seguinte forma: um Covenant sela um conteúdo até que uma condição seja satisfeita. As suas partes encriptadas são distribuídas por um comité de nós, para que nenhum operador consiga reconstruir o conteúdo original sozinho. Quando a condição é satisfeita, os nós publicam as suas partes, permitindo que o conteúdo seja reconstruído e verificado na Ethereum antes de ocorrer a ação subsequente.
A distinção fundamental está entre o mecanismo documentado — selar uma instrução até que uma condição seja satisfeita — e as garantias de segurança mais abrangentes, que dependem da implementação e das premissas do protocolo.
Consideremos uma transação condicional associada a uma fonte de preços. Se essa fonte estiver desatualizada ou for imprecisa, manter a instrução encriptada não torna os dados que desencadeiam a ação fiáveis. A confidencialidade protege a estratégia contra a exposição prematura; por si só, não garante que a condição seja avaliada corretamente. Por isso, as premissas de confiança subjacentes ao acionamento e à revelação são tão importantes quanto o mecanismo de privacidade.
A questão mais profunda é em que é que o sistema tem de confiar. Uma condição correta, uma revelação legítima e a confidencialidade são requisitos distintos. Proteger o conteúdo não prova automaticamente que o acionamento foi avaliado corretamente ou que a revelação respeitou as regras pretendidas. Essas garantias dependem do modelo de verificação do protocolo e das suas premissas.
Para que a execução condicionada se torne prática, o que merece maior escrutínio: a fiabilidade do acionamento, a integridade da revelação ou as premissas em que o protocolo se baseia para proteger ambos?
$NIL