رفتن به متن مستندات
پلانکمستندات
مرجع API/API شبکه و قرارداد ارتباطی Station
پیاده‌سازی‌شده

API شبکه و قرارداد ارتباطی Station

لایه‌های JSON-RPC، API کنترل‌گر، عامل Station و درگاه Remote؛ با مثال‌های خواندنی و بدون نشانی عملیاتی.

توسعه‌دهندگان یکپارچه‌سازی و اپراتورهای مجازبازبینی: ۲ مهر ۱۴۰۵
در این صفحههر API برای یک مخاطب استخواندن هویت و وضعیت BesuAPI کنترل‌گر و وضعیت عملیاتعضویت و منابع Stationقرارداد خواندنی Remoteپیش‌شرط اتصال واقعی

هر API برای یک مخاطب است

API مارکت‌پلیس با API زیرساخت Admin Main، عامل Station و JSON-RPC Besu متفاوت است. این مستند یک endpoint عمومی واحد برای همه آن‌ها معرفی نمی‌کند؛ مبدأ و احراز هویت باید از مدیر همان استقرار دریافت شود.

روش‌های خواندن Besu داده زنجیره را می‌دهند. API کنترل‌گر می‌تواند عملیات مدیریتی داشته باشد. Agent Station دامنه ایستگاه را اعمال می‌کند و Remote Gateway فقط قرارداد خواندنی محدود خود را در اختیار کلاینت می‌گذارد.

خواندن هویت و وضعیت Besu

روش‌های مورد استفاده در سورس شامل eth_chainId، net_version، eth_blockNumber، eth_getBlockByNumber، eth_syncing، net_peerCount، eth_getBalance و qbft_getValidatorsByBlockNumber هستند. بعضی تشخیص‌های مدیریتی از admin_nodeInfo و روش‌های QBFT استفاده می‌کنند؛ این مجوزها نباید بدون نیاز در RPC عمومی قرار گیرند.

پاسخ eth_syncing=false فقط می‌گوید نود در آن لحظه فرایند sync گزارش نمی‌کند؛ تازگی Head، پیشروی بلاک و هم‌خوانی شاخه هنوز باید بررسی شوند. برای تطبیق شبکه، هش بلاک صفر از داده RPC گرفته می‌شود.

json
{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x0",false]}

API کنترل‌گر و وضعیت عملیات

Admin Main مسیرهایی مانند /health، /api/production/readiness و /api/state دارد. APIهای شبکه، قرارداد، خزانه و رأی، عملیات داخلی مدیریتی‌اند. در حالت تولید، توکن برنامه و تنظیم درگاه لازم است و بعضی عملیات حساس نشست امنیتی مستقل می‌خواهند.

عملیات طولانی باید از شناسه کار و نتیجه ثبت‌شده پیگیری شوند. موفقیت پاسخ HTTP آغاز عملیات، با نهایی‌شدن عضویت QBFT یا موفقیت تراکنش برابر نیست. تکرار درخواست نیز باید سیاست idempotency همان endpoint را رعایت کند.

عضویت و منابع Station

عامل Station مسیرهای /api/v1/membership/status، /api/v1/membership/request و /api/v1/membership/activation را برای عضویت دارد. اتصال مرجع، امضاکننده و آمادگی در شاخه /api/v1/production مدیریت می‌شوند. کشف و binding در /api/v1/nodes قرار دارند.

ثبت تصمیم وظیفه از مسیر /api/v1/tasks/{task_id}/decisions انجام می‌شود و شناسه درخواست و نسخه سیاست بخشی از کنترل تکرار و هم‌زمانی‌اند. پاسخ READY_FOR_SIGNATURE را نباید امضای تکمیل‌شده یا tx hash معتبر تلقی کرد.

قرارداد خواندنی Remote

درگاه Remote بدنه‌ای با action برابر snapshot یا block می‌پذیرد؛ برای block شماره غیرمنفی در محدوده Head لازم است. روش RPC از کلاینت دریافت نمی‌شود. سرور برای هر درخواست توکن، زمان اعتبار، نقش و هویت مجاز را تعیین می‌کند.

پاسخ شامل نسخه قرارداد، زمان تولید، هویت مجاز همان ایستگاه، شبکه، منابع، وضعیت Admin Main، خلاصه نود و بلاک‌های عمومی است. تعداد منابع بین یک تا چهار محدود می‌شود؛ منابع باید Chain ID، Network ID و Genesis یکسان داشته باشند و هش ارتفاع مشترک آن‌ها تطبیق کند.

json
{"action":"snapshot"}

پیش‌شرط اتصال واقعی

برای یکپارچه‌سازی، محیط، نسخه سرویس، نقش، دامنه دسترسی، سیاست خطا و انقضا باید ثبت شوند. مقدار unknown یا unavailable باید حفظ شود؛ اتصال قطع‌شده نباید با یک پاسخ موفق نمونه پوشانده شود.

درگاه Remote در گزارش انتشار مستقرشده روی تولید معرفی نشده است و مسیر امضای سازمانی Station نیز به سرویس واقعی وابسته است. نمونه‌های این صفحه قرارداد داده را توضیح می‌دهند و هیچ آدرس، credential یا دستور تراکنش واقعی در خود ندارند.

مراجع پیاده‌سازی این صفحه

این مسیرها نام فایل‌های مبنای مستندات‌اند؛ دسترسی به مخزن یا محیط خصوصی ایجاد نمی‌کنند.

  • admin-main-new/backend/app/main.py
  • admin-main-new/backend/app/services/rpc_service.py
  • plank-station-new/agent/app.py
  • plank-station-mac-remote/server/gateway.py
  • plank-station-mac-remote/src/remote.ts
  • plank-station-mac-remote/VERIFICATION_REMOTE_FA.md