Deterministic WebAssembly Sandbox | Dweve Selvedge

Selvedge runs untrusted code in a deterministic WebAssembly sandbox and returns a replayable run record. Publishing in the fourth release round.

Compilar cargas de trabalho Kera BNN para o runtime Selvedge.

Proveniência de eventos com cadeia de hash para eventos do sistema.

Certificados de prova de raciocínio, não transcrições de execução.

A Selvedge publica na quarta ronda do programa de lançamento da fundação, depois da Knot e da Ledger. Quando isso acontecer, coloque um módulo WASM em sandbox e reproduza o envelope de prova você mesmo.

Superfície de execução de ferramentas do Model Context Protocol.

Selado com Ed25519, transcrição SHA3-256, verificação offline.

Redes neuronais binárias IR de grafo, JIT e intérprete.

Runtime de modelo de componentes, anfitrião WASI 0.2 Preview 2.

A Selvedge executa código não confiável dentro de uma sandbox com limites de capacidade e regista a execução numa transcrição selada. A contenção limita o que o código pode tocar; a transcrição mostra o que realmente aconteceu e pode ser reproduzida para revisão.

Servidor Model Context Protocol para ferramentas de agente.

Runtime de agente de longa duração com fila.

build, verify, run, replay. Compatível com CI.

Ferramentas de agente, plugins de terceiros, inferência Kera BNN e trabalho com dados regulados entram todos pela mesma fronteira controlada. Cada runtime produz o mesmo envelope de evidência selado, pelo que as mudanças de implementação não alteram a história de auditoria.

Assinatura Ed25519 5-15 us, verificação 15-30 us.

Arranque do processo incluído, 8 a 9 vezes mais rápido.

Módulo de computação, vs. 1187-1494 us vanilla.

O arranque do Selvedge Wasmtime é 62 a 243 vezes mais rápido do que o Wasmtime vanilla ao nível da API. A troca honesta está no caminho quente: o vanilla mantém a chamada repetida de 22 ns, e o modelo de componente que produz o registo é mais lento aí. O Kera JIT é 2 vezes mais rápido a quente para trabalho de grafos. Os números vêm do BENCHMARKS.md do repositório.

Escolha o runtime para a carga de trabalho

Cada decisão de gate é registada e tem hash.

max_execution_time_ns, separado do fuel.

max_memory_bytes, 256 MiB por omissão, teto de 4 GiB.

max_instructions, a exaustão termina a carga de trabalho de forma limpa.

Relógio, aleatório, sistema de ficheiros, rede, ambiente, stdio, processo, personalizado. Negação por omissão.

Um conjunto de capacidades de negação por omissão controla cada chamada de host em oito domínios WASI. Os limites de recursos em memória, fuel e tempo limitam o comportamento descontrolado. Cada decisão de gate e leitura de recursos está no registo.

Precisa de prova criptográfica do que a carga de trabalho fez, não de confiança no runtime.

Confie no runtime, não na carga de trabalho

Permitir sistema de ficheiros, negar rede, mas sem registo por chamada na trilha de auditoria.

FP e tempo real vazam. A repetição produz aproximadamente o mesmo resultado, não exatamente.

Uma sandbox impede a fuga. Não prova que a carga de trabalho se comportou corretamente no interior.

As sandboxes convencionais impedem que código mau escape. Não produzem um registo do que o código realmente fez no interior. Quando um auditor pergunta, a resposta é uma afirmação, não evidência.

O Selvedge captura exatamente o que foi executado, da entrada à saída, cada chamada de host selada.

O ledger regista o que aconteceu num sistema. O Selvedge regista o que o código fez.

A AION emite certificados sobre os passos do solver, não sobre execuções.

Como o Selvedge difere da AION e do Ledger

As mesmas entradas mais o mesmo envelope significam a mesma saída, sempre.

Uma época fixa e um PRNG ChaCha20 com semente substituem o tempo do host e a entropia.

A computação, o armazenamento e a acumulação internos usam representações binárias, inteiras, de ponto fixo ou inteiro/ponto fixo adaptativas. O ponto flutuante é aceite apenas numa fronteira externa declarada e é explicitamente convertido antes de o trabalho interno começar; não há recurso interno a ponto flutuante. O relógio virtual permanece fixo, pelo que a repetição produz os mesmos bytes.

Execução determinística por predefinição

O verificador repete offline apenas com os bytes do módulo e o envelope.

Assinatura ed25519 sobre a raiz do envelope. Não prosa.

Cada chamada do host é incluída no hash da cadeia. As edições quebram a cadeia.

Porque é que a transcrição é diferente de um registo

O mesmo fluxo em cada execução. A repetição é mecânica.

Prova AION emitida, assinada com ed25519, envelope pronto a enviar.

Cada chamada do host e resultado incluídos no hash de uma cadeia SHA3-256.

O Wasmtime ou a Kera executa dentro da sandbox de negação por predefinição.

Módulo carregado, capacidades fixadas, limites de recursos aplicados.

O Selvedge executa código WASM ou Kera dentro de uma sandbox de negação por predefinição, inclui cada chamada do host no hash de uma cadeia de transcrição SHA3-256 e envolve o resultado num envelope de prova AION assinado. O envelope repete sem a sandbox original.

O Selvedge é uma sandbox WebAssembly determinística para código não fiável. O seu manifesto de permissões e a transcrição selada são executados em hardware que controla, pelo que uma contraparte pode repetir o registo na sua própria máquina e uma disputa torna-se uma consulta em vez de um pedido de garantia.

Mantenha o código dentro dos limites, mantenha o registo

A Selvedge coloca um programa que não escolheu numa sala sem internet, sem rota para os seus ficheiros e sem nada para aprender sobre a sua máquina. Deixa um recibo a dizer o que voltou e o que o programa tinha permissão para fazer, para que possa verificar uma alegação posterior em vez de aceitar a palavra de alguém.

A Selvedge executa código que não escreveu num anfitrião de componentes WebAssembly sem rede, sistema de ficheiros, ambiente ou relógio em movimento. Cada execução concluída devolve um registo que outra parte pode reproduzir e um relatório de execução a indicar o que o código tinha permissão para fazer. Publicado sob Apache 2.0.

Execute código não confiável no hardware que controla.

Um ambiente isolado WebAssembly determinístico.

A publicação está planeada em rondas quinzenais. O repositório e a sua documentação são disponibilizados em conjunto.

Faz uma pequena tarefa, aqui, e em nenhum outro lugar.

Selado, para que nada possa ser alterado

Execução concluída com sucesso em 18.4ms

A sala, o recibo e a lista são toda a promessa.

O código é transportado em cada execução.

Aqui chega como uma lista. Cada tarefa que usou o programa defeituoso identifica-o por código, data e uma lista curta de permissões, para que possa ver o que foi afetado e até onde poderia ter ido. Se as pessoas que o criaram deixarem de ser de confiança, a retirada entra em vigor num intervalo de atualização definido, em vez de quando um certificado expira. O software é publicado sob a licença Apache 2.0.

A versão habitual desta conversa é uma estimativa. Alguém calcula qual a versão que provavelmente estava em execução, em que dias, para que pessoas, e a resposta chega como um intervalo com uma ressalva. Isso deixa os factos necessários para delimitar uma correção como uma reconstrução, em vez de um registo. A correção começa com uma lista que pode ser verificada.

Cada tarefa regista um código curto para o programa exato que fez o trabalho. Não o seu nome, não o seu número de versão, mas o programa em si, para que duas compilações que partilham um nome tenham códigos diferentes. Se esse programa vier a revelar-se defeituoso, o código é como cada tarefa que ele tocou é encontrada.

Quando algo corre mal, um código identifica o programa.

O programa em si é carregado de novo de cada vez a partir do seu próprio código, e o recibo transporta um código para esse código, para que o que correu hoje seja comprovadamente o que correu no mês passado. Nada se acumula pelo meio para preocupar alguém mais tarde.

Uma nova sala Selvedge custa tão pouco que uma por tarefa é acessível, por isso nada tem de ser partilhado. Se algo precisar genuinamente de ser transportado, é entregue de propósito e aparece no registo como algo que foi entregue.

Cada tarefa recebe uma nova sala. Nada da anterior está nela: sem notas deixadas, sem trabalho a meio, sem memória de quem pediu. Isto parece óbvio e geralmente não é verdade, porque manter uma sala de pé é mais barato do que construir uma nova, por isso a maioria dos sistemas mantém a sala e reutiliza-a.

Uma nova sala está pronta para a próxima tarefa.

Saída, resultado e utilização de recursos.

Não encontrar nada é uma prova fraca, porque depende de quão bem alguém procurou e de quanto tempo teve antes da reunião. Uma lista de duas permissões é uma prova forte, porque não havia mais nada para encontrar.

Muda o que acontece quando se faz uma pergunta mais tarde. Em vez de alguém rever o que o programa fez e reportar que não encontrou nada preocupante, a lista de permissões está ali, e é curta.

A maioria dos registos diz o que um programa fez. Um recibo Selvedge também diz o que lhe foi permitido fazer, o que é uma coisa diferente e mais útil. Um programa que nunca teve permissão para chegar perto dos seus ficheiros não pode ter estado perto deles, e isso fica registado, quer alguém estivesse a observar no momento ou não.