פיתוח תשתית ל-Bitcoin Ordinals

לקוח רצה להשיק שוק Ordinals ברשת הראשית של ביטקוין, אך נתקל בבעיה: סנכרון מלא של Bitcoin Core ארך שבועיים, ומדד ה-ord קרס עם שגיאת OOM בבלוק 750,000. התצורה הסטנדרטית לא התחשבה במאפייני נתוני witness — נדרשו אופטימיזציית זיכרון ו-ZMQ לעדכונים בזמן אמת. כתבנו מחדש חלק מהמדד בשפת Rust, וקיצרנו את זמן הסנכרון ל-8 שעות.

מקרה זה הוא דוגמה טיפוסית לכך שתשתית Ordinals דורשת גישה שונה מפיתוח EVM קונבנציונלי. במאמר זה, נפרק החלטות ארכיטקטוניות מרכזיות ונשתף תצורות אמיתיות.

כיצד פועלים Ordinals ו-Inscriptions טכנית

תורת הסידור מקצה לכל סאטושי מספר רציף לפי סדר הכרייה. מספר הסאטושי הוא דטרמיניסטי — מחושב מגובה הבלוק ומהמיקום בעסקת coinbase. העברת ordinals פירושה הזזת סאטושי ספציפי עם סדר קלט/פלט נכון.

Inscriptions הם נתונים שרירותיים המוטמעים בשדה witness של העסקה באמצעות תבנית envelope:

OP_FALSE OP_IF OP_PUSH "ord" // маркер OP_PUSH 1 // tag: content-type OP_PUSH "image/png" // MIME тип OP_PUSH 0 // tag: content OP_PUSH <data_chunk1> // данные (до 520 байт на чанк) OP_PUSH <data_chunk2> // продолжение ... OP_ENDIF 

OP_FALSE OP_IF OP_PUSH "ord" // маркер OP_PUSH 1 // tag: content-type OP_PUSH "image/png" // MIME тип OP_PUSH 0 // tag: content OP_PUSH <data_chunk1> // данные (до 520 байт на чанк) OP_PUSH <data_chunk2> // продолжение ... OP_ENDIF יוצר ענף שלעולם לא מתבצע, אך הנתונים מאוחסנים ב-witness. לאחר Taproot (BIP 341), נתוני witness זולים בכ-4x מנתוני עסקה רגילים. זה הפך את Ordinals לכדאיים כלכלית.

מנגנון commit-reveal: יצירת Inscription דורשת שתי עסקאות. עסקת ה-Commit מכילה פלט P2TR עם התחייבות לסקריפט המכיל את ה-inscription. עסקת ה-Reveal מוציאה את הפלט הזה, וחושפת את הסקריפט עם הנתונים. זה מונע front-running.

מדוע Ordinals דורשים תשתית שונה מ-EVM

חוזים חכמים ב-EVM כוללים מצב, אירועים ו-ABI. לביטקוין אין אף אחד מאלה. כל הלוגיקה בנויה סביב UTXO ונתוני witness. מדדים חייבים לפרש את תוכן ה-witness בעצמם, ולא להסתמך על שיטות RPC סטנדרטיות. ייצור דורש טיפול מותאם במקרי קצה כמו ניסיונות double-spend ב-BRC-20. הצוות שלנו, עם ניסיון של למעלה מ-5 שנים בפיתוח Bitcoin Core, מבטיח אימות חזק וסנכרון נתונים באמצעות מדדים קנייניים.

אופטימיזציית ביצועים וטיפול בעומס גבוה

שוק עם אלפי עסקאות ביום זקוק לארכיטקטורה בעלת ביצועים גבוהים. אנו משתמשים ב-sharding של PostgreSQL לפי טווח סאטושי, מטמון Redis, ועיבוד אסינכרוני באמצעות RabbitMQ. זה מתמודד עם עד 1000 בקשות בשנייה ללא ירידה בביצועים. לדוגמה, לקוח אחד הפחית את עלויות התשתית ב-30% (חיסכון של למעלה מ-$20,000 בשנה) לאחר אימוץ התצורה האופטימלית שלנו.

הקמת תשתית צומת

Bitcoin Core + מדד ord

מחסנית ייצור מינימלית: Bitcoin Core (צומת מלא, pruned אינו מתאים) → מדד ord → PostgreSQL/RocksDB → API

Bitcoin Core דורש מצב ארכיון (ללא pruning) — Ordinals זקוקים לגישה לנתוני witness של כל העסקאות ההיסטוריות. גודל בזמן כתיבת מאמר זה: ~700GB וגדל. SSD חובה.

# bitcoin.conf txindex=1 server=1 rpcuser=rpc rpcpassword=strong_password rpcallowip=127.0.0.1 zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28333 

OP_FALSE OP_IF — יישום מדד ייחוס מאת Casey Rodarmor. סנכרון ראשוני אורך 12–48 שעות. בייצור, השרת פועל מאחורי nginx עם מטמון.

דרישות שרת

פיתוח מדד מותאם אישית

שרת ה-ord מכסה שאילתות בסיסיות, אך עבור מוצרים מורכבים (שוק, אנליטיקת אוספים, inscriptions הורה-ילד) נדרש מדד מותאם אישית.

from bitcoinrpc.authproxy import AuthServiceProxy import json rpc = AuthServiceProxy("http://rpc:[email protected]:8332") def parse_inscription_from_tx(txid: str) -> dict | None: """Извлекает inscription из reveal транзакции""" raw = rpc.getrawtransaction(txid, True) for vin in raw.get("vin", []): witness = vin.get("txinwitness", []) for item in witness: script_bytes = bytes.fromhex(item) inscription = try_parse_inscription_script(script_bytes) if inscription: return inscription return None def try_parse_inscription_script(script: bytes) -> dict | None: """Парсит ord envelope из witness script""" try: idx = script.index(b"\x00\x63") except ValueError: return None # Дальнейший парсинг ~100 строк pass 

Inscriptions הורה-ילד

מאז ord 0.6+, נתמכים inscriptions הורה — אוספי NFT עם פרובננס. לצורך אינדוקס שלהם, אנו משתמשים ביחס מפתח זר.

CREATE TABLE inscriptions ( id TEXT PRIMARY KEY, sat BIGINT NOT NULL, content_type TEXT, content_length INTEGER, block_height INTEGER NOT NULL, parent_id TEXT REFERENCES inscriptions(id), created_at TIMESTAMP NOT NULL ); 

תקני טוקנים: BRC-20 ו-Runes

BRC-20 משתמש בתוכן JSON ב-inscriptions כפעולות. יתרות נקבעות לחלוטין על ידי המדד. לייצור, נדרשת הקפדה קפדנית על מפרט מדד l1brc20.

Runes — תקן מאת מחבר Ordinals (שוחרר לאחרונה). המצב מאוחסן ב-UTXOs, מה שמפחית את עומס המדד. # bitcoin.conf txindex=1 server=1 rpcuser=rpc rpcpassword=strong_password rpcallowip=127.0.0.1 zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28333 תומך ב-Runes באופן טבעי מאז גרסה 0.17.

פעולות נאמנות באמצעות PSBT

שוק דורש PSBT (עסקאות ביטקוין חתומות חלקית). המוכר חותם על UTXO של ה-inscription, והקונה מוסיף את הקלטים שלו. אנו מיישמים שרשרת רישום והחלפה מלאה ללא אחסון כספים מרכזי.

הקמת תשתית שלב אחר שלב

1. פריסת Bitcoin Core במצב ארכיון עם txindex ו-ZMQ מופעלים.
2. התקנת מדד ord וביצוע סנכרון ראשוני (12–48 שעות).
3. הגדרת PostgreSQL או RocksDB לאחסון נתוני inscriptions.
4. פיתוח מדד מותאם אישית עבור BRC-20/Runes (במידת הצורך).
5. בניית שכבת API עם מטמון והרשאות.
6. שילוב מנגנון PSBT עבור השוק.
7. בדיקות על testnet וביצוע בדיקות עומס.
8. ניטור באמצעות ZMQ והגדרת התראות.

עם ניסיון של 5+ שנים ולמעלה מ-50 פרויקטי תשתית בלוקצ'יין מוצלחים, אנו מבטיחים זמינות של 99.9% עבור מערכות ייצור.

לוח זמנים ומה כלול

תשתית מלאה לשוק Ordinals: 5–8 שבועות. מדד + API בלבד: 2–3 שבועות.

העלות לפרויקטים כאלה מחושבת באופן פרטני, אך חיסכון טיפוסי מאופטימיזציית נתוני witness יכול להגיע ל-30% (לדוגמה, $15,000–$30,000 בשנה עבור פלטפורמות בעלות נפח גבוה). לקוחות שאימצו את הארכיטקטורה שלנו מפחיתים את עלויות התשתית בממוצע של 20–40% בהשוואה לפתרונות סטנדרטיים.

אם אתם מתכננים להשיק שוק Ordinals או לשלב BRC-20/Runes, צרו קשר — נעזור לתכנן ולפרוס תשתית מוכנה לייצור. קבלו ייעוץ לפרויקט שלכם — נעריך את הארכיטקטורה ונמצא את הפתרון האופטימלי.