Deterministic WebAssembly Sandbox | Dweve Selvedge

Compiler les charges de travail BNN de Kera pour l'exécution Selvedge.

Provenance des événements chaînée par hachage pour les événements système.

Certificats de preuve de raisonnement, pas de transcriptions d'exécution.

Selvedge publie au quatrième tour du programme de publication de la fondation, après Knot et Ledger. Une fois publié, testez un module WASM dans un bac à sable et rejouez l'enveloppe de preuve vous-même.

Surface d'exécution des outils du protocole de contexte de modèle.

Scellé Ed25519, transcription SHA3-256, vérification hors ligne.

Réseaux de neurones binaires IR graphique, JIT et interpréteur.

Runtime de modèle de composants, hôte WASI 0.2 Preview 2.

Selvedge exécute du code non fiable dans un bac à sable à capacités limitées et enregistre l'exécution dans une transcription scellée. Le confinement limite ce que le code peut toucher ; la transcription montre ce qui s'est réellement passé et peut être rejouée pour examen.

Serveur de protocole de contexte de modèle pour les outils d'agents.

Runtime d'agent de longue durée avec une file d'attente.

construire, vérifier, exécuter, rejouer. Compatible CI.

Lié à votre application en tant que crate.

Les outils d'agents, les plugins tiers, l'inférence BNN Kera et le travail sur les données réglementées passent tous par la même frontière contrôlée. Chaque runtime produit la même enveloppe de preuve scellée, donc les changements de déploiement ne modifient pas l'histoire d'audit.

répond aux charges de travail réglementées

Démarrage à froid, la victoire principale

Signature Ed25519 5-15 us, vérification 15-30 us.

Démarrage du processus inclus, 8 à 9 fois plus rapide.

Module de calcul, contre 1187-1494 us vanilla.

Selvedge Wasmtime démarre 62 à 243 fois plus vite que Wasmtime vanilla au niveau de l'API. Le compromis honnête est le chemin à chaud : vanilla conserve l'appel répété de 22 ns, et le modèle de composants qui produit le transcript y est plus lent. Kera JIT est 2 fois plus rapide à chaud pour le travail sur graphe. Les chiffres proviennent du BENCHMARKS.md du dépôt.

Chaque décision de contrôle est enregistrée et hachée.

max_memory_bytes, 256 MiB par défaut, plafond de 4 GiB.

max_instructions, l'épuisement arrête proprement la charge.

Horloge, aléa, système de fichiers, réseau, environnement, stdio, processus, personnalisé. Refus par défaut.

Un ensemble de capacités en refus par défaut contrôle chaque appel hôte sur huit domaines WASI. Les limites de ressources sur la mémoire, le fuel et le temps bornent les comportements incontrôlés. Chaque décision de contrôle et lecture de ressource figure dans le transcript.

Vous avez besoin de preuves cryptographiques de ce que la charge a fait, pas de confiance dans le runtime.

Faites confiance au runtime, pas à la charge

Autoriser le système de fichiers, refuser le réseau, mais aucun enregistrement par appel dans la piste d'audit.

FP et temps réel fuient. La relecture produit approximativement la même sortie, pas exactement.

Un sandbox empêche l'évasion. Il ne prouve pas que la charge s'est comportée correctement à l'intérieur.

Les sandboxes conventionnels empêchent le code malveillant de s'échapper. Ils ne produisent pas d'enregistrement de ce que le code a réellement fait à l'intérieur. Quand un auditeur demande, la réponse est une affirmation, pas une preuve.

Selvedge capture exactement ce qui a été exécuté, de l'entrée à la sortie, chaque appel hôte scellé.

Le registre enregistre ce qui s'est passé dans un système. Selvedge enregistre quel code a tourné.

AION émet des certificats sur les étapes de résolution, pas sur les exécutions.

En quoi Selvedge diffère d'AION et de Ledger

Mêmes entrées plus même enveloppe signifient même sortie, toujours.

Une époque fixe et un PRNG ChaCha20 ensemencé remplacent le temps hôte et l'entropie.

Le calcul interne, le stockage et l'accumulation utilisent des représentations binaires, entières, à virgule fixe ou adaptatives entières/à virgule fixe. La virgule flottante n'est acceptée qu'à une frontière externe déclarée et est explicitement convertie avant le début du travail interne ; il n'y a pas de repli interne en virgule flottante. L'horloge virtuelle reste fixe, donc la relecture produit les mêmes octets.

Pas de flottants internes, pas d'horloges

Le vérificateur rejoue hors ligne avec les octets du module et l'enveloppe seuls.

Signature ed25519 sur la racine de l'enveloppe. Pas de prose.

Chaque appel hôte est haché dans la chaîne. Les modifications cassent la chaîne.

Pourquoi le transcript diffère d'un journal

Même flux à chaque exécution. La relecture est mécanique.

Preuve AION émise, signée ed25519, enveloppe prête à expédier.

Chaque appel hôte et résultat est haché dans une chaîne SHA3-256.

Wasmtime ou Kera s'exécute dans le sandbox à refus par défaut.

Module chargé, capacités épinglées, limites de ressources appliquées.

Selvedge exécute du code WASM ou Kera dans un sandbox à refus par défaut, hache chaque appel hôte dans une chaîne de transcript SHA3-256, et enveloppe le résultat dans une enveloppe de preuve AION signée. L'enveloppe se rejoue sans le sandbox d'origine.

Selvedge est un sandbox WebAssembly déterministe pour code non fiable. Son manifeste de permissions et son transcript scellé s'exécutent sur du matériel que vous contrôlez, donc une contrepartie peut rejouer l'enregistrement sur sa propre machine et un litige devient une consultation plutôt qu'une demande d'assurance.

Gardez le code dans les limites, gardez la trace

Selvedge place un programme que vous n'avez pas choisi dans une pièce sans internet, sans accès à vos fichiers et sans rien à apprendre sur votre machine. Il laisse un reçu indiquant ce qui est revenu et ce que le programme était autorisé à faire, afin que vous puissiez vérifier une affirmation ultérieure au lieu de prendre quelqu'un au mot.

Selvedge exécute du code que vous n'avez pas écrit dans un hôte de composants WebAssembly sans réseau, système de fichiers, environnement ni horloge mobile. Chaque exécution terminée renvoie un enregistrement qu'une autre partie peut rejouer, ainsi qu'un rapport d'exécution indiquant ce que le code était autorisé à faire. Publié sous Apache 2.0.

Exécutez du code que vous n'avez pas écrit.

Exécutez du code non fiable sur du matériel que vous contrôlez.

Un bac à sable WebAssembly déterministe.

La publication est prévue par tours bimensuels. Le dépôt et sa documentation sont mis en ligne ensemble.

Il fait une petite tâche, ici, et nulle part ailleurs.

Scellé, pour que rien ne puisse être modifié

Exécution terminée avec succès en 18,4 ms

La pièce, le reçu et la liste constituent toute la promesse.

Le code est transporté à chaque exécution.

Ici, cela arrive sous forme de liste. Chaque tâche ayant utilisé le programme défectueux le nomme par code, date et une courte liste de permissions, afin que vous puissiez voir ce qui a été affecté et jusqu'où cela aurait pu aller. Si les personnes qui l'ont créé ne sont plus dignes de confiance, le retrait prend effet à un intervalle d'actualisation défini plutôt qu'à l'expiration d'un certificat. Le logiciel est publié sous licence Apache 2.0.

La version habituelle de cette conversation est une estimation. Quelqu'un détermine quelle version tournait probablement, quels jours, pour quelles personnes, et la réponse arrive sous forme de fourchette avec une réserve. Cela laisse les faits nécessaires pour délimiter une correction comme une reconstruction plutôt qu'un enregistrement. La correction commence par une liste vérifiable.

Chaque tâche enregistre un code court pour le programme exact qui a effectué le travail. Pas son nom, pas son numéro de version, le programme lui-même, de sorte que deux versions partageant un même nom aient des codes différents. Si ce programme s'avère ensuite défectueux, le code est ce qui permet de retrouver chaque tâche qu'il a touchée.

Quand quelque chose s'avère erroné, un code nomme le programme.

Le programme lui-même est chargé à neuf à chaque fois depuis son propre code, et le reçu porte un code pour ce code, de sorte que ce qui a tourné aujourd'hui est prouvablement ce qui a tourné le mois dernier. Rien ne s'accumule entre-temps pour que quiconque s'en inquiète plus tard.

Une nouvelle pièce Selvedge coûte si peu qu'une par tâche est abordable, donc rien ne doit être partagé. Si quelque chose doit vraiment être transporté, cela se fait intentionnellement et cela apparaît dans l'enregistrement comme quelque chose qui a été transmis.

Chaque tâche reçoit une nouvelle pièce. Rien de la précédente ne s'y trouve : pas de notes laissées, pas de travail à moitié fini, pas de mémoire de qui a demandé. Cela semble évident et ce ne l'est généralement pas, car garder une pièce debout coûte moins cher que d'en construire une nouvelle, donc la plupart des systèmes gardent la pièce et la réutilisent.

Une nouvelle pièce est prête pour la prochaine tâche.

Sortie, résultat et utilisation des ressources.

Ne rien trouver est une preuve faible, car cela dépend de l'effort de recherche et du temps disponible avant la réunion. Une liste de deux permissions est une preuve forte, car il n'y avait rien d'autre à trouver.