بررسی بلاک چین‌‌‌ لیبرا (رمز ارز فیسبوک)

من به تازگی یک سند فنی 26 صفحه‌‌‌ای درباره‌‌‌ پروتکل مورد استفاده به عنوان پلتفرم برای سکه لیبرا (Libra) را بررسی کردم. این سند را 53 کارشناس نوشته‌‌‌اند!

 

مقدمه

پروتکل لیبرا این امکان را فراهم می‌‌‌سازد که مجموعه‌‌‌ای از تکرارها (replica) که به آن‌‌‌ها اعتبارسنج (validator) می‌‌‌گویند، از مراجع (authorities) گوناگون با هم یک دیتابیس از منابع برنامه‌‌‌پذیر را تشکیل دهند.

بسیار خوب، نیازی نیست پیچیده صحبت کنیم. سیستم از بالا تا پایین به دست یک مجموعه از مراجع کنترل می‌‌‌شود. البته باید توجه داشت که گفته شده این دیتابیس برای «منابع برنامه‌‌‌پذیر» است نه فقط یک رمز ارز.

این منابع متعلق به حساب‌‌‌های کاربری گوناگونی هستند که دسترسی به آن‌‌‌ها با کریپتوگرافی کلید عمومی انجام می‌‌‌شود و قوانین شخصی سازندگان این منابع در آن‌‌‌ها رعایت می‌‌‌شود.

استفاده از واژه‌‌‌های کلی مانند «منابع» این اندیشه را در من به وجود آورد که داستان بسیار فراتر از یک استیبل کوین (stablecoin) است.

تراکنش‌‌‌ها بر مبنای قراردادهای هوشمند از پیش‌‌‌ تعیین شده (و در نسخه‌‌‌های آینده «تعریف شده به دست کاربر») و در یک زبان برنامه‌‌‌نویسی تازه به نام Move انجام می‌‌‌شوند. ما از Move برای تعریف مکانیزم‌‌‌های اساسی بلاک چین‌‌‌ مانند ارز و عضویت اعتبارسنج استفاده نموده‌‌‌ایم.

بسیار خوب، گویا داستان دارد جالب می‌‌‌شود. استفاده از یک زبان برای نوشتن قراردادهای شخصی دلخواه پرسش‌‌‌های زیادی را به دنبال دارد؛ از جمله اینکه این زبان از چه توانایی‌‌‌هایی برخوردار است و در نتیجه گستردگی این سیستم در مقایسه با قراردادهای موجود در سیستم‌‌‌های رقیب چقدر است. پرسش‌‌‌های دیگری نیز پیش می‌‌‌آید؛ اینکه نویسندگان چقدر با لیبرا راحت هستند و لیبرا چگونه از آسیب زدن توسعه دهندگان قراردادهای هوشمند به خودشان جلوگیری می‌‌‌کند.

این مکانیزم‌‌‌های اساسی به یک مکانیزم اداره‌‌‌ی منحصر به فرد می‌‌‌انجامند که در ابتدا بر پایداری و اعتبار موسسات موجود تکیه می‌‌‌کند ولی به تدریج به یک سیستم کاملا منبع – باز تبدیل می‌‌‌شود.

گویا «انجمن لیبرا» (Libra Association) به مانند یک فدراسیون است که به وسیله‌‌‌ی رای و نوعی شیوه‌‌‌ اعتباری، رشد و نمود پیدا خواهد کرد.

1. مقدمه

این اکوسیستم یک ارز جهانی جدید به نام سکه لیبرا (Libra coin) به وجود می‌‌‌آورد که به طور کامل از پشتیبانی سبد سپرده‌‌‌های بانکی و خزانه‌‌‌های بانک‌‌‌های مرکزی درجه یک برخوردار است.

لیبرا نوعی پروتکل دارایی کریپتو است و نخستین دارایی آن یک استیبل کوین خواهد بود.

به مرور زمان، امکان عضویت تغییر می‌‌‌کند و کاملا آزاد می‌‌‌شود، به نحوی که تنها لازمه‌‌‌ی آن داشتن لیبرا خواهد بود.

این رویه بسیار شبیه اثبات سهام (PoS) است. گویا برنامه این است که عضویت پس از 5 سال آزاد شود و آن‌‌‌ها تا آن زمان مساله‌‌‌ی اثبات سهام را حل خواهند کرد. انتظار من این است که آن‌‌‌ها مانند اتریوم به مشکلاتی بر بخورند.

«انجمن» گزارش‌‌‌هایی منتشر کرده که نقشه راه گذار به سوی یک سیستم بی‌‌‌مجوز (permissionless) را نشان می‌‌‌دهند.

من کاملا مطمئنم این نخستین شبکه‌‌‌ی توزیع شده در جهان خواهد بود که از حالت مجوزدار به بی‌‌‌مجوز گذار می‌‌‌کند. شاید کلیت شبکه بتواند به حالت اثبات سهام (PoS) تغییر پیدا کند ولی برای ادامه‌‌‌ی کار سبد استیبل کوین، گروهی از نهادها باید پلی با سیستم مالی سنتی را برای خود نگه دارند. همین کار به عامل کنترل متمرکز از سوی «انجمن لیبرا» تبدیل می‌‌‌شود.

اعتبارسنج‌‌‌ها به صورت نوبتی فرآیند پذیرش تراکنش‌‌‌ها را به عهده می‌‌‌گیرند. هنگامی که یک اعتبارسنج نقش لیدر را بازی می‌‌‌کند، تراکنش‌‌‌هایی را به دیگر اعتبارسنج‌‌‌ها می‌‌‌دهد. برخی از این تراکنش‌‌‌ها را کلاینت‌‌‌ها مستقیما برای اعتبارسنج لیدر فرستاده‌‌‌اند و بخش دیگر به صورت غیرمستقیم از سوی اعتبارسنج‌‌‌های دیگر به دست لیدر رسیده. همه‌‌‌ی اعتبارسنج‌‌‌ها تراکنش‌‌‌ها را اجرا کرده و نوعی ساختار دیتای تایید شده را ایجاد می‌‌‌کنند که تاریخچه‌‌‌ی دفتر ثبت جدید (new ledger history) را در خود دارد. اعتبارسنج‌‌‌ها برای برگزیدن تایید کننده (authenticator) این ساختار دیتا رای می‌‌‌دهند و این کار بخشی از پروتکل اجماع است.

این ساز و کار شبیه «تلورانس خطای بیزانسی کاربردی» (Practical Byzantine Fault Tolerance) است. یک الگوریتم 20 ساله‌‌‌ی جا افتاده که احتمالا برای استفاده از آن در این ساز و کار با چند ابتکار همراه شده است. در بخش 5 از وایت پیپر این سیستم که LibraBFT توضیحاتی داده شده که نشان می‌‌‌دهد روش به کار رفته در لیبرا یک گونه از پروتکل اجماع هات‌‌‌استاف (HotStuff) است.

بخشی از اجرای تراکنش Ti در نسخه i شامل ایجاد یک خرویج از پروتکل اجماع است. این خروجی یک امضاء برای حالت کامل (full state) دیتابیس در نسخه‌‌‌ی i (شامل همه‌‌‌ی تاریخچه‌‌‌ی آن) است که پاسخ پرسش‌‌‌های انجام شده از کلاینت‌‌‌ها را تایید می‌‌‌کند.

این مساله بدین خاطر مهم است که نشان می‌‌‌دهد اعتبارسنج‌‌‌های جدید باید بتوانند در شبکه عضو شوند و بی‌‌‌درنگ و بدون نیاز به بازاجرای تمامی تاریخچه بلاک چین‌‌‌ (با فرض اعتماد آن‌‌‌ها به اعتبارسنج‌‌‌های موجود)، با شبکه سینک گردند.

2. مدل دیتای منطقی

پروتکل لیبرا برای انکود کردن حالت دفتر ثبت از یک مدل دیتای مبتنی بر اکانت استفاده می‌‌‌کند.

از دید ساختار دیتا، لیبرا بیشتر شبیه اتریوم و ریپل (Ripple) است تا بیت کوین. به کارگیری مدل UTXO مزایا و معایب خود را دارد. برای نمونه حریم خصوصی را بهبود می‌‌‌بخشد و به خاطر سادگی تاریخچه‌‌‌ مبتنی بر خروجی، تاریخچه‌‌‌ی تراکنش‌‌‌ها را کامل‌‌‌تر می‌‌‌سازد ولی به سختی می‌‌‌تواند با قراردادهای هوشمند پیچیده کار کند. از این رو به کارگیری مدل اکانت منطقی به نظر می‌‌‌رسد، زیرا بعید است فیسبوک با وجود علاقمندی آشکار خود به قراردادهای هوشمند در مورد حریم خصوصی نگران باشد.

پروتکل لیبرا اکانت‌‌‌ها را به هویت‌‌‌های حقیقی افراد پیوند نمی‌‌‌دهد. هر کاربر آزاد است به تعداد دلخواه برای خود اکانت بسازد و چندین جفت کلید داشته باشد. اکانت‌‌‌هایی که از آن یک کاربر است هیچ پیوند درونی با یکدیگر ندارند. این رویه با ایجاد امکان ناشناس ماندن برای کاربران از رویکرد بیت کوین و اتریوم پیروی می‌‌‌کند.

این شرایط خوب است، ولی من دوست دارم بدانم آیا در مورد دارایی‌‌‌های سکه لیبرا هم همین‌‌‌طور است یا نه. جالب است ببینیم این سیستم برای آن دسته از نویسندگانی که می‌‌‌خواهند اپلیکیشن بسازند و به حریم خصوصی خود بیشتر اهمیت می‌‌‌دهند تا چه اندازه باز است.

هر منبعی از یک گونه است که به وسیله‌‌‌ی ماژول اعلام می‌‌‌شود. گونه‌‌‌های منابع در حقیقت انواع اسمی هستند که شامل نام گونه و نام و آدرس ماژول اعلام کننده‌‌‌ی منبع می‌‌‌باشند.

گویا می‌‌‌توان آدرس ساخت و به تعداد دلخواه دارایی به آن منتصب نمود. تنها کافی است هر دارایی یک اسم منحصر به فرد داشته باشد.

اجرا نمودن تراکنش Ti به ایجاد یک حالت دفتر ثبت تازه به نام Si می‌‌‌شود و با به اجرا درآمدن کد حالت، مصرف gas و لیست رویداد همراه است.

اکنون می‌‌‌دانیم سیستم چگونه در برابر حمله‌‌‌ی اتلاف منابع از خود محافظت می‌‌‌کند. به وسیله‌‌‌ی یک مکانیزم هزینه‌‌‌ی منبع مانند آنچه در اتریوم وجود دارد.

در تاریخچه‌‌‌ دفتر ثبت سیستم هیچ مفهومی به نام بلوک تراکنش وجود ندارد

جالب است که در پروتکل لیبرا عملا ساختار دیتای بلاک چین‌‌‌ وجود ندارد. جنس بلوک‌‌‌ها بیشتر مجازی و منطقی است و کار آن‌‌‌ها هماهنگ ساختن برهه‌‌‌های تایید شده از حالت سیستم است. اکنون نخستین جمله‌‌‌ی این بخش بیش از پیش آشکار می‌‌‌شود:

تمامی دیتای بلاک چین‌‌‌ لیبرا در یک دیتابیس تک نسخه‌‌‌ای ذخیره می‌‌‌شود. شماره‌‌‌ی نسخه یک اینتیجر 64 بیتی بدن علامت (عدد صحیح بی علامت) است که برابر با شمار تراکنش‌‌‌های اجرا شده در سیستم می‌‌‌باشد.

هر شبکه‌‌‌ی دارایی کریپتو که من می‌‌‌شناسم به همین شیوه و در یک سطح بسیار بالا کار می‌‌‌کند. یک حالت سیستم وجود دارد. ابتدا یک تراکنش اجرا می‌‌‌شود که با کارکرد موثر گذار حالت همراه است و پس از آن یک حالت سیستم جدید به وجود می‌‌‌آید.

 

هدف از قرار دادن دسته‌‌‌های تراکنش در بسته‌‌‌ها (بلوک‌‌‌ها) این است که کار ترتیب‌‌‌بندی (ordering) و زدن تایم‌‌‌استمپ (timestamping) انجام شود. این رویه برای شبکه‌‌‌های بی‌‌‌مجوز بسیار اهمیت دارد. در این شبکه‌‌‌ها، دیتا به وسیله‌‌‌ی امضاهای چندجانبه‌‌‌ی اعضاء (در حالت دینامیک) تایید می‌‌‌شود و اعتبارسنج‌‌‌ها می‌‌‌توانند آزادانه در شبکه عضو و از آن خارج شوند. با توجه به اینکه لیبرا با یک سیستم مجوزدار کار می‌‌‌کند، می‌‌‌تواند از یک الگوریتم اجماع کارآمدتر استفاده کند که در آن نیازی به دسته کردن تراکنش‌‌‌ها نیست، زیرا احتمال بازنویسی تاریخچه‌‌‌ی تراکنش‌‌‌ها بسیار کمتر است.

در نخستین ورژن پروتکل لیبرا، تنها یک زیرمجموعه‌‌‌ی محدود از کارکردهای «Move» در دسترس کاربران قرار دارد. «Move» برای تعریف سیستم مرکزی مانند ارز لیبرا به کار می‌‌‌رود و کاربران نمی‌‌‌توانند برای اعلام گونه‌‌‌ی منبع خود ماژول‌‌‌های سفارشی ایجاد کنند. این رویکرد به زبان «Move» و زنجیره‌‌‌ی ابزاری (toolchain) امکان می‌‌‌دهد پیش از قرار گرفتن در اختیار کاربران رشد و نمو کنند (به کمک تجربه‌‌‌ی اجرای اجزای سیستم مرکزی). از سوی دیگر این رویکرد رویارویی با چالش‌‌‌های مقیاس‌‌‌پذیری را به تاخیر می‌‌‌اندازد؛ چالش‌‌‌هایی در اجرای تراکنش و ذخیره‌‌‌ی دیتا که بخشی از ماهیت پلتفرم‌‌‌های قرارداد هوشمند همه‌‌‌ – منظوره می‌‌‌باشند.

این رویکرد بسیار شبیه طرح‌‌‌های «عضویت آزاد اعتبارسنج» به نظر می‌‌‌رسد که پیش‌‌‌تر به آن‌‌‌ها اشاره شد. گویا فیسبوک هیچ یک از مشکلات بزرگی که اتریوم سال‌‌‌ها با آن‌‌‌ها دست و پنجه نرم می‌‌‌کند را حل نکرده است.

به منظور مدیریت تقاضا برای ظرفیت محاسبه، پروتکل لیبرا برای تراکنش‌‌‌ها کارمزد دریافت می‌‌‌کند که برحسب سکه لیبرا می‌‌‌باشد.

جالب است. پس سکه‌‌‌ لیبرا در حقیقت یک واحد درونی از پروتکل هستند، درست مانند ETH که واحد درونی اتریوم است. به این ترتیب پرسش‌‌‌های بیشتری درباره‌‌‌ی ماهیت ناشناس لیبرا به وجود می‌‌‌آید. آیا می‌‌‌توان بدون AML/KYC به سکه دست پیدا کرد؟ اگر نمی‌‌‌شود پس گویا امکان استفاده‌‌‌ی ناشناس از هیچ یک از کارکردهای سیستم وجود ندارد. با توجه به مطالب موجود درباره‌‌‌ی کیف پول کالیبرا (Calibra) مشخص است که این کیف پول نیازمند AML/KYC است. بنابراین مایلم بدانم آیا بالاخره این سیستم دارای مسیرهایی خواهد بود که در آن‌‌‌ها خبری از کنترل سفت و سخت نباشد؟

سیستم به گونه‌‌‌ای طراحی شده که در هنگام کارکرد عادی که ظرفیت کافی در دسترس است، کارمزد بسیار پایینی دارد.

این گفته بسیار مبهم است و پرسش‌‌‌های زیادی برمی‌‌‌انگیزد. این کارمزد پایین چه هست؟ کارکرد عادی چیست؟ ظرفیت کافی چیست؟

3. اجرای تراکنش‌‌‌ها

… بسیاری از بخش‌‌‌های منطق مرکزی بلاک چین‌‌‌ به وسیله‌‌‌ی Move تعریف شده‌‌‌اند. از جمله اندازه‌‌‌گیری کارمزد gas. به منظور جلوگیری از چرخش دایره‌‌‌وار، در هنگام اجرای این بخش‌‌‌های مرکزی، VM اندازه‌‌‌گیری gas را خاموش می‌‌‌کند.

این رویه بسیار خطرناک به نظر می‌‌‌رسد ولی نویسنده اشاره می‌‌‌کند که اجزای مرکزی باید برای مقاومت در برابر حملات DoS به صورت دفاعی نوشته شوند.

ویژگی کلیدی Move توانایی‌‌‌اش در تعریف گونه‌‌‌های منبع سفارشی است … سیستم گونه‌‌‌ی Move، ضمانت‌‌‌‌‌‌های امنیتی ویژه‌‌‌ای برای منابع به وجود می‌‌‌آورد. هرگز نمی‌‌‌توان یک منبع را کپی یا جابه‌‌‌جا کرد. این ضمانت‌‌‌ها در حالت ایستا به وسیله‌‌‌ی VM Move اعمال می‌‌‌شوند. این کار به ما امکان می‌‌‌دهد سکه‌‌‌های لیبرا را به عنوان یک گونه‌‌‌ی منبع در زبان Move به کار بگیریم.

به این ترتیب به پرسش پیشین که آیا سکه لیبرا به مانند ETH و BTC یک دارایی درونی است یا خیر پاسخ داده شد. از دید من سکه لیبرا در هنگام راه‌‌‌اندازی سیستم، گونه‌‌‌ی پیش‌‌‌فرض و تنها گونه‌‌‌‌‌‌‌‌‌ی مجاز از منبع است و در پی آن منابع دیگر خواهند آمد.

بایت‌‌‌کد مبتنی بر پشته‌‌‌ (stack-based bytecode) زبان Move، نسبت به یک زبان منبع سطح – بالاتر عادی، دستورات (instruction) کمتری دارد. افزون بر این، هر یک از دستورها معنای ساده‌‌‌ای دارد که می‌‌‌توان آن را حتی به وسیله‌‌‌ی شمار کمتری از مراحل اتمی (atomic steps) بیان کرد. این مساله باعث کمتر شدن مشخصه‌‌‌های ویژه در پروتکل لیبرا شده و اجرای بدون اشتباه آن را آسان‌‌‌تر می‌‌‌سازد.

گویا به خوبی درباره‌‌‌ این مسائل اندیشیده شده و امید می‌‌‌رود امنیت زبان اسکریپت نویسی لیبرا از اتریوم بهتر باشد.

4. ساختارهای دیتا و ذخیره تایید شده

پروتکل لیبرا در راستای بهره‌‌‌گیری از یک ساختار دیتای تایید شده (authenticated) برای تاریخچه دفتر ثبت از یک درخت مرکل (Merkle tree) استفاده می‌‌‌کند … به طور مشخص، تاریخچه‌‌‌ی دفتر ثبت با به کارگیری رویکرد انباشتگر (accumulator) درخت مرکل، افزون بر ساختن درختان مرکل، امکان انجام کارآمد عملیات‌‌‌های افزوده‌‌‌ای را فراهم می‌‌‌سازد.

یک بار دیگر می‌‌‌بینیم که «بلاک چین‌‌‌ لیبرا» در حقیقت یک بلاک چین‌‌‌ نیست. بسیار شگفت‌‌‌آور است که این پروتکل با وجود طراحی بسیار خوب از سوی سازندگانش بلاک چین‌‌‌ نامیده می‌‌‌شود، در حالی که ساختار دیتای تاریخچه‌‌‌ی دفتر ثبت مجموعه‌‌‌ای از حالت‌‌‌های دفتر ثبت امضاء شده است. اعتبارسنج‌‌‌ها برای هر یک از حالت‌‌‌های دفتر ثبت، الزاماتی ایجاد می‌‌‌کنند. همه‌‌‌ی حالت‌‌‌های بایگانی شده‌‌‌ دفتر ثبت مقید به درخت‌‌‌های مرکل هستند، ولی من هنوز در این سیستم لیستی از دیتا که پیوند خورده باشد (backlinked) و یک زنجیره را تشکیل دهد نمی‌‌‌بینم چه برسد به یک زنجیره‌‌‌ی بلوکی.

آنچه که اکانت‌‌‌ها را تایید می‌‌‌کند، هش این طرح سریالی است. باید توجه داشت که این طرح پس از هر بار تغییر در اکانت، تاییدگر را ملزم به محاسبه‌‌‌ی دوباره‌‌‌ی همه‌‌‌ی اکانت می‌‌‌سازد. هزینه‌‌‌ی این عملیات O(n) است که در آن n درازای طرح کل اکانت به صورت بایت می‌‌‌باشد.

اگر هیچ محدودیتی برای میزان دیتای ذخیره شده از سوی هر اکانت وجود نداشته باشد، به نظر شبیه به یک بردار DoS است.

پیش‌‌‌بینی ما این است که پس از به کارگیری سیستم، بالاخره رشد ذخیره‌‌‌سازی نسبت به شمار اکانت‌‌‌ها به یک مشکل تبدیل شود. همان گونه که gas انگیزه‌‌‌ای برای مصرف مسئولانه‌‌‌ منابع کامپیوتری (محاسباتی) است، به باور ما برای ذخیره‌‌‌سازی نیاز به یک مکانزیم مشابه و مبتنی بر کرایه است. در حال حاضر سرگرم ارزیابی رنج گسترده‌‌‌ای از شیوه‌‌‌ها برای مکانزیم کرایه‌‌‌ای (rent-based) تا مناسب‌‌‌ترین روش برای اکوسیستم را پیدا کنیم.

یک مشکل حل نشده‌‌‌ی دیگر. گویا ممکن است در آینده باز هم جمله‌‌‌ی کلیشه‌‌‌ای «چقدر اجاره‌‌‌ها بالا رفته» را بشنویم.

قدرت رای‌‌‌دهی باید در دوره‌‌‌ی ابتدایی کار و همچنین مدتی پس از این دوره درستکار باقی بماند تا کلاینت‌‌‌ها بتوانند با پیکربندی جدید همسان‌‌‌سازی (سینک) شوند. اگر کلاینتی به مدت بیش از این دوره آفلاین بماند باید به وسیله‌‌‌ی برخی منابع بیرونی حقیقت خود را دوباره همسان‌‌‌سازی (ری‌‌‌سینک) کند تا به یک نقطه‌‌‌ی قابل اعتماد برسد.

روشن نیست «این دوره» چقدر طول می‌‌‌کشد، ولی من حدس می‌‌‌زنم کمتر از یک روز باشد. به نظر می‌‌‌رسد این پروتکل اجماع آنقدر توانمند نیست که شرکت کنندگان بتوانند به میل خود شبکه را ترک کنند و بار دیگر در آن عضو شوند.

5. اجماع تلورانس خطای بیزانسی

در LibraBFT (تلورانس خطای بیزانسی لیبرا) فرض بر این است که یک مجموعه‌‌‌ی 3f+1 رایی میان گروهی از اعتبارسنج‌‌‌ها توزیع می‌‌‌شود که ممکن است پاکدست یا بیزانسی باشند. هنگامی که بیشتر رای‌‌‌ها در دست‌‌‌ اعتبارسنج‌‌‌های بیزانسی باشد، LibraBFT با پیشگیری از حملاتی مانند پرداخت دوبل و فورک‌‌‌ها امنیت خود را تامین می‌‌‌کند.

درست مانند PBFT این الگوریتم اجماع هم می‌‌‌تواند تخلف 33% از اعتبارسنج‌‌‌ها را تحمل کند. به نظر می‌‌‌رسد اصلاحات هات‌‌‌استاف کاملا سنجیده هستند:

1. مقاوت در برابر باگ‌‌‌های غیرقطعی از راه وا داشتن اعتبارسنج‌‌‌ها به امضای حالت بلوک به جای امضای توالی تراکنش‌‌‌ها.
2. وجود یک تنظیم کننده که آشکارا وقفه‌‌‌هایی را اعلام می‌‌‌کند و اعتبارسنج‌‌‌ها بر مبنای به حد نصاب رسیدن این وقفه‌‌‌ها برای رفتن به دور بعد اقدام می‌‌‌کنند. این مساله باعث افزایش همراهی و در جریان بودن می‌‌‌شود.
3. یک ساز و کار غیر قابل پیش‌‌‌بینی رای‌‌‌گیری برای برگزیدن لیدر که امکان حمله‌‌‌ی DoS به لیدر را محدود می‌‌‌سازد.
4. انباشت امضاها از یکسان بودن اعتبارسنج‌‌‌هایی که برای رای دادن به پذیرش بلوک، اثبات حد نصاب را امضاء می‌‌‌کنند جلوگیری می‌‌‌نماید.

6. شبکه‌‌‌بندی

در پروتکل لیبرا هر اعتبارسنج از یک نمای عضویتی کامل از سیستم برخوردار است و می‌‌‌تواند یکراست به هر اعتبارسنجی که نیازمند ارتباط با آن باشد متصل گردد. اعتبارسنجی که نتواند به صورت مستقیم متصل شود، از سوی سیستم در بخش خطای بیزانسی تحمل شده قرار می‌‌‌گیرد.

دادن مقیاس به این سیستم و گسترش دادن آن به بیش از چند صد اعتبارسنج نیاز به کار بسیار زیادی دارد.

7. پیاده‌‌‌سازی هسته لیبرا

امنیت بلاک چین‌‌‌ لیبرا به پیاده‌‌‌سازی درس اعتبارسنج‌‌‌ها، برنامه‌‌‌های Move و Move VM بستگی دارد. پرداختن به این مسائل در هسته لیبرا (Libra Core) کاری است که سازندگان هم‌‌‌اکنون سرگرم آن هستند.

این یک جمع‌‌‌بندی کلی از مطالب این بخش است. البته آن‌‌‌ها نوشته‌‌‌اند کار پیاده‌‌‌سازی در «راست» (Rust) انجام می‌‌‌شود که شروع خوبی برای دستیابی به نتیجه‌‌‌ی کارایی و امنیتی مناسب است.

8. کارایی

پیش‌‌‌بینی ما این است که پروتکل لیبرا در آغاز راه‌‌‌اندازی بتواند در هر ثانیه 1,000 تراکنش پرداخت را پشتیبانی نماید و میان درخواست تراکنش و به اجرا درآمدن آن یک زمان انجام 10 ثانیه‌‌‌ای وجود داشته باشد.

از آنجایی که تنها نزدیک به 100 اعتبارسنج وجود خواهد داشت و آن‌‌‌ها با یکدیگر ارتباط مستقیم دارند، زمان بلوک 10 ثانیه‌‌‌ای شدنی به نظر می‌‌‌رسد.

کمترین نیازهای هر گره:

• اینترنت با سرعت 40 Mbps
• یک CPU معمولی
• یک حافظه‌‌‌ی 16 ترابایتی (16 TB SSD)

در بخش‌‌‌های پیشین اشاره شده که به جای اعتماد کردن به حالت‌‌‌های امضاء شده به دست دیگر اعتبارسنج‌‌‌ها، یک اعتبارسنج باید بتواند سینک ابتدایی را از صفر اجرا نماید. از دید من حتی اگر لیبرا بتواند کاربران زیادی پیداکند، خیلی زود اجرای چنین سینکی ناممکن خواهد شد و در نتیجه مدل امنیت گره به کار رفته به شدت به اعتماد به اعتبارسنج‌‌‌ها وابسته می‌‌‌گردد.

9. پیاده سازی سیاست‌‌‌های اکوسیستم لیبرا به وسیله‌‌‌ Move

اندوخته (سکه لیبرا) ساز و کار اصلی برخورداری از امکان نگهداری از ارزش می‌‌‌باشد. با وجود این اندوخته، هر سکه از پشتیبانی مجموعه‌‌‌ای از دارایی‌‌‌های پایدار و نقدی برخوردار است. قرارداد سکه لیبرا اجازه می‌‌‌دهد در صورت افزایش تقاضا، انجمن اقدام به تولید سکه نماید و پس از برطرف شدن تقاضا آن‌‌‌ها را از بین ببرد. انجمن سیاست پولی مشخصی را دنبال نمی‌‌‌کند بلکه تنها می‌‌‌تواند در واکنش به درخواست از سوی فروشندگان معتبر، اقدام به ایجاد یا حذف سکه نماید. نیازی نیست کاربران نگران ایجاد تورم در سیستم یا کاهش ارزش پول از سوی انجمن باشند. در ازای هر سکه‌‌‌ای که تولید می‌‌‌شود، مقداری پول نقد متناسب با آن ذخیره می‌‌‌گردد.

بسیار خوب، اکنون داریم درباره‌‌‌ی رویدادهایی حرف می‌‌‌زنیم که بیرون از شبکه رخ می‌‌‌دهند. همان گونه که پیش‌‌‌تر در وایت پیپر اشاره شده، شبکه‌‌‌ لیبرا نمی‌‌‌تواند از اسکریپت‌‌‌هایی که در آن‌‌‌ها ورودی دیتا بیرون از حالت شبکه است استفاده کنند. بنابراین واژه‌‌‌های «می‌‌‌تواند» و «باید» که در بخش‌‌‌ بالا به کار رفته به سیاست‌‌‌های انجمن لیبرا یا تعهدات قراردادی که شبکه از آن‌‌‌ها آگاه نیست اشاره دارند.

الگوریتم اجماع با تکیه بر ماژول Move مدیریت مجموعه اعتبارسنج‌‌‌ها (validator-set)، در هر زمان از گروه اعتبارسنج‌‌‌ها حراست کرده و توزیع رای میان آن‌‌‌ها را مدیریت می‌‌‌نماید. در ابتدای کار، بلاک چین‌‌‌ لیبرا تنها به اعضای بنیان‌‌‌گذار امکان رای می‌‌‌دهد.

اگر اعتبارسنج‌‌‌ها به بروز تغییر در مجموعه اعتبارسنج‌‌‌ها رای دهند، انتظار می‌‌‌رود مشکلی همانند آنچه در سیستم‌‌‌های اثبات سهام دیده شده (حملات دوربرد) رخ دهد. اگر شمار مشخصی از کلید‌‌‌های خصوصی اعضای بنیان‌‌‌گذار لو برود، آیا حمله‌‌‌ کننده‌‌‌ها می‌‌‌توانند از نو و از پیدایش، تاریخچه‌‌‌ی دفتر ثبت جدیدی بنویسند؟ اگر این طور است آیا گره‌‌‌های دیگر این دفتر ثبت تازه را می‌‌‌پذیرند؟ روشن نیست که آیا پروتکل اجماع اجازه‌‌‌ی بازنویسی حالت‌‌‌های گذشته را می‌‌‌دهد و یا تنها مجوز برای افزودن می‌‌‌دهد.

برنامه ما این است که رفته رفته به سمت اثبات سهام برویم.

اگر آن‌‌‌ها بتوانند مشکلات حل نشده را حل کنند.

پرسش‌‌‌های مهم

حاکمیت سیستم به چه شکل انجام می‌‌‌شود؟

در اینجا می‌‌‌توان دید که انجمن لیبرا یک شورا است و برای انجام هر تغییری نیاز به اکثریت 3/2 دارد. تنها این انجمن است که اجازه دارد سکه لیبرا تولید کند یا از بین ببرد ولی روی کاغذ، آن‌‌‌ها در صورت رسیدن به اتفاق نظر کافی می‌‌‌توانند هر کاری که بخواهند را انجام دهند.

آیا به AML/KYC نیاز است؟

گویا در شرایط کنونی پروتکل، نیازی به آن نیست. اما کیف پول کالیبرا اعلام کرده همه‌‌‌ی کاربران باید به وسیله‌‌‌ی شناسه (ID) دولتی تایید شوند. به نظر می‌‌‌رسد کیف پول کالیبرا دسته‌‌‌کم تا مدتی تنها کیف پول موجود برای لیبرا خواهد بود. روشن نیست آیا نویسندگان و کاربران لیبرا می‌‌‌توانند روی شبکه‌‌‌ی لیبرا اپلیکیشن‌‌‌هایی که از قوانین کالیبرا پیروی نمی‌‌‌کنند را اجرا کنند یا خیر.

کارمزدهای پایین چقدر است؟ کارکرد عادی چیست؟ ظرفیت کافی چقدر است؟

بخش آگاهی رسانی کیف پول کالیبرا خبر از کارمزدهای پایین داده ولی به نظر می‌‌‌رسد این مساله در هنگام بالا رفتن حجم کاری با پروتکل موجود ناهمخوانی داشته باشد.

کارمزدهای تراکنش در سطح پایین و شفاف خواهند بود؛ به ویژه اگر بخواهید به صورت درونی پول ارسال کنید. کالیبرا با حذف کارمزد به افراد کمک می‌‌‌کند پول خود را کمتر از دست بدهند.

آیا لیبرا واقعا برای توسعه دهندگان باز خواهد بود؟

براساس برنامه‌‌‌ی حرکت به سمت اجماع بی‌‌‌مجوز:

بلاک چین‌‌‌ لیبرا برای همگان باز خواهد بود. هر مشتری، توسعه دهنده یا بیزنسی که بخواهد می‌‌‌تواند از شکه لیبرا استفاده کند، در آن محصولات خود را بسازد و از راه سرویس‌‌‌های این محصولات به ارزش خود بیفزاید. دسترسی باز باعث از میان رفتن موانع موجود بر سر راه ورود و نوآوری شده و انگیزه‌‌‌ساز رقابت سالم است؛ خصوصیتی که مشتری از آن سود خواهد برد.

من تردید دارم که توسعه دهندگان بتوانند هر اپلیکیشنی را که به لحاظ فنی معتبر است، به دلخواه روی این پلتفرم اجرا کنند. هیچکدام از نوشته‌‌‌هایی که خوانده‌‌‌ام من را به این باور نرسانده که این سیستم در برابر سانسور مقاومت خواهد کرد. گذر زمان همه‌‌‌چیز را روشن خواهد کرد!

منبع