zeroboot

صناديق رملية افتراضية دون الميلي ثانية لوكلاء الذكاء الاصطناعي عبر التفرّع بالنسخ عند الكتابة

---

جرّبه

curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'

المعايير القياسية

المقياس	Zeroboot	E2B	microsandbox	Daytona
زمن الاستجابة عند الإنشاء p50	0.79ms	~150ms	~200ms	~27ms
زمن الاستجابة عند الإنشاء p99	1.74ms	~300ms	~400ms	~90ms
الذاكرة لكل صندوق رمل	~265KB	~128MB	~50MB	~50MB
Fork + exec (Python)	~8ms	-	-	-
1000 عملية fork متزامنة	815ms	-	-	-

كل صندوق رمل هو جهاز افتراضي KVM حقيقي مع عزل للذاكرة مفروض على مستوى العتاد.

كيف يعمل

  Firecracker snapshot ──► mmap(MAP_PRIVATE) ──► KVM VM + restored CPU state
                              (copy-on-write)         (~0.8ms)

1. القالب (لمرة واحدة): يُقلع Firecracker جهازًا افتراضيًا، ويحمّل بيئة التشغيل مسبقًا، ويأخذ لقطة لحالة الذاكرة + المعالج
2. التفرّع (~0.8ms): ينشئ جهازًا افتراضيًا KVM جديدًا، ويُعيّن ذاكرة اللقطة كـ CoW، ويستعيد كامل حالة المعالج
3. العزل: كل تفرّع هو جهاز افتراضي KVM منفصل مع عزل ذاكرة مفروض عتاديًا

حزم SDK

Python — sdk/python

from zeroboot import Sandbox
sb = Sandbox("zb_live_your_key")
result = sb.run("print(1 + 1)")

TypeScript — sdk/node

import { Sandbox } from "@zeroboot/sdk";
const result = await new Sandbox("zb_live_your_key").run("console.log(1+1)");

المستندات

• مرجع API
• دليل النشر
• البنية المعمارية

المؤلف

أُنشئ Zeroboot في مارس 2026 ويُشرف عليه Adam Miribyan (@adammiribyan). موقع المشروع: zeroboot.dev.

إذا استخدمت zeroboot في البحث العلمي، فيرجى الاستشهاد به؛ راجع CITATION.cff أو استخدم زر "Cite this repository".

مقتبس في

• DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback، arXiv:2605.22781 (مايو 2026).
• Memory Compression for High-Fanout Agent Sandboxes (AgentZip)، arXiv:2609.11294 (سبتمبر 2026).

إذا كان بحثك أو مشروعك يستخدم zeroboot، فافتح issue أو pull request لإضافته هنا.

الحالة

نموذج أولي عامل. إن primitive الخاص بالتفريع (fork) وbenchmarks وAPI حقيقية، لكنها لم تُقسَّ بعد لبيئة الإنتاج. افتح issue إذا كنت مهتمًا.

الاستضافة الذاتية أو المُدارة

Zeroboot مفتوح المصدر. استضفه ذاتيًا على أي جهاز Linux يدعم KVM، أو استخدم API المُدارة:

curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'

نعمل على بناء الخدمة المُدارة للفرق التي لا ترغب في تشغيل بنيتها التحتية الخاصة. سجّل للحصول على وصول مبكر: https://tally.so/r/aQGkpb

القيود المعروفة

• تشارك عمليات التفريع (forks) حالة CSPRNG من اللقطة (snapshot). يُعاد بذر عشوائية النواة (kernel entropy) عبر RNDADDENTROPY، لكن مولدات الأرقام العشوائية الزائفة في مساحة المستخدم (numpy، OpenSSL) تحتاج إلى إعادة بذر صريحة لكل fork. راجع إرشادات Firecracker.
• vCPU واحدة لكل fork. تعدد vCPU ممكن معماريًا لكنه غير مُنفَّذ.
• لا يوجد اتصال شبكي داخل عمليات التفريع (forks). تتواصل بيئات العزل (sandboxes) عبر الإدخال/الإخراج التسلسلي (serial I/O) فقط.
• تتطلب تحديثات القوالب إعادة أخذ لقطة كاملة (~15 ثانية). لا يوجد ترقيع تزايدي.

الترخيص

Apache-2.0