اتریوم چیست؟

وایت‌پیپر اتریوم در سال ۲۰۱۴ و پیش از راه‌اندازی این شبکه منتشر شد. پس از بیش از ۱۰ سال توسعه، ارتقاهای عمده و رشد زیست‌بوم اتریوم، وایت‌پیپر اولیه دیگر بازتاب‌دهنده وضعیت امروزی اتریوم نیست. با وجود گذشت چندین سال، متن اصلی همچنان نگهداری می‌شود، زیرا هنوز مرجعی سودمند است و اتریوم و چشم‌انداز آن را به‌درستی بازنمایی می‌کند.

پلتفرمی نسل بعدی برای قراردادهای هوشمند و برنامه‌های غیرمتمرکز

ساخت بیت‌کوین به دست ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب تحولی بنیادین در عرصه پول و ارز دانسته شده است. بیت‌کوین نخستین نمونه از یک دارایی دیجیتال بود که نه پشتوانه یا «ارزش ذاتی» داشت و نه صادرکننده یا کنترل‌کننده‌ای متمرکز. بااین‌حال، بخش دیگری از آزمایش بیت‌کوین که شاید حتی مهم‌تر باشد، فناوری بلاک‌چینِ زیربنایی آن است؛ فناوری‌ای که به‌عنوان ابزاری برای دستیابی به اجماع توزیع‌شده عمل می‌کند. توجه‌ها با شتاب در حال معطوف‌شدن به همین جنبه دیگر بیت‌کوین است.

از جمله کاربردهای جایگزینی که معمولاً برای فناوری بلاک‌چین مطرح می‌شوند، می‌توان به استفاده از دارایی‌های دیجیتال ثبت‌شده روی بلاک‌چین برای بازنمایی ارزهای سفارشی و ابزارهای مالی، موسوم به «سکه‌های رنگی»، اشاره کرد. بازنمایی مالکیت یک دستگاه فیزیکی زیربنایی نیز با مفهوم «دارایی هوشمند» مطرح می‌شود. دارایی‌های غیرمثلی مانند نام‌های دامنه، از جمله در پروژه «نیم‌کوین» (Namecoin)، نمونه دیگری هستند.

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

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

آشنایی با بیت‌کوین و مفاهیم موجود

مفهوم ارز دیجیتال غیرمتمرکز و نیز کاربردهای جایگزینی مانند دفاتر ثبت مالکیت، دهه‌هاست که مطرح شده‌اند. پروتکل‌های پول نقد الکترونیکی ناشناس در دهه‌های ۱۹۸۰ و ۱۹۹۰ عمدتاً بر یک ابزار پایه‌ای رمزنگاری به نام «پنهان‌سازی چامی» متکی بودند. این پروتکل‌ها ارزی با سطح بالایی از حریم خصوصی فراهم می‌کردند، اما چون به یک واسطه متمرکز وابسته بودند، در مجموع نتوانستند رواج چندانی پیدا کنند.

در سال ۱۹۹۸، طرح «بی‌مانی» (b-money) وِی دای نخستین پیشنهادی بود که هم ایده ایجاد پول از طریق حل معماهای محاسباتی را مطرح کرد و هم مفهوم اجماع غیرمتمرکز را پیش کشید. بااین‌حال، این پیشنهاد درباره چگونگی اجرای عملی اجماع غیرمتمرکز جزئیات اندکی ارائه می‌کرد.

با وجود این، طرح فینی نیز به وضعیت مطلوب نرسید، زیرا در زیرساخت پشتیبان خود به رایانش مورد اعتماد وابسته بود.

هال فینی در سال ۲۰۰۵ مفهوم «اثبات‌های کارِ قابل‌استفاده مجدد» را معرفی کرد. این سامانه، ایده‌هایی از بی‌مانی را با معماهای محاسباتی دشوار «هش‌کش» متعلق به آدام بک ترکیب می‌کرد تا مفهومی برای یک رمزارز بسازد. با وجود این، طرح فینی نیز به وضعیت مطلوب نرسید، زیرا در زیرساخت پشتیبان خود به رایانش مورد اعتماد وابسته بود.

سرانجام در سال ۲۰۰۹، ساتوشی ناکاموتو برای نخستین بار یک ارز غیرمتمرکز را در عمل پیاده‌سازی کرد. ناکاموتو ابزارهای پایه‌ای و تثبیت‌شده برای مدیریت مالکیت از طریق رمزنگاری کلید عمومی را با یک الگوریتم اجماع ترکیب کرد؛ الگوریتمی که مشخص می‌کرد سکه‌ها در مالکیت چه کسانی هستند و با نام «اثبات کار» شناخته می‌شود.

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

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

اثبات کار برای رسیدن به این هدف، مانع رسمیِ مشارکت را با مانعی اقتصادی جایگزین می‌کند. یک مانع رسمی ممکن است الزام افراد به ثبت‌شدن به‌عنوان موجودیتی یکتا در فهرستی خاص باشد. اما در اثبات کار، وزن هر گره در فرایند رأی‌گیری اجماع مستقیماً با توان محاسباتی‌ای تناسب دارد که همان گره در اختیار شبکه می‌گذارد.

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

بیت‌کوین به‌عنوان یک سامانه گذار حالت

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

برای نمونه، در یک نظام بانکی متعارف، «حالت» همان ترازنامه است. «تراکنش» نیز درخواستی برای انتقال مبلغ X دلار از شخص یا حساب A به شخص یا حساب B است. تابع گذار حالت، مقدار X دلار را از حساب A کم و همان مقدار را به حساب B اضافه می‌کند. اگر حساب A از ابتدا کمتر از X دلار موجودی داشته باشد، تابع گذار حالت خطا برمی‌گرداند. بنابراین می‌توان این سازوکار را به‌طور رسمی چنین تعریف کرد:

در نظام بانکی تعریف‌شده در بالا:

اما:

«حالت» در بیت‌کوین مجموعه تمام سکه‌هایی است که ایجاد شده‌اند اما هنوز خرج نشده‌اند. اصطلاح فنی این سکه‌ها «خروجی‌های خرج‌نشده تراکنش» است که با سرواژه UTXO شناخته می‌شوند. هر UTXO یک ارزش اسمی و یک مالک دارد. مالک با یک نشانی ۲۰ بایتی مشخص می‌شود که در اصل نوعی کلید عمومی رمزنگاری‌شده است¹.

هر تراکنش شامل یک یا چند ورودی است.

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

تابع گذار وضعیت را می‌توان به‌طور تقریبی به‌شکل زیر تعریف کرد:

APPLY(S, TX) → S′

برای هر ورودی در TX:

۱. اگر UTXO مورد اشاره در وضعیت S وجود ندارد، خطا برگردان.

۲. اگر امضای ارائه‌شده با مالک UTXO مطابقت ندارد، خطا برگردان.

۳. اگر مجموع ارزش اسمی همهٔ UTXOهای ورودی کمتر از مجموع ارزش اسمی همهٔ UTXOهای خروجی است، خطا برگردان.

۴. وضعیت S را پس از حذف همهٔ UTXOهای ورودی و افزودن همهٔ UTXOهای خروجی برگردان.

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

برای استفاده از این سازوکار در پرداخت، پروتکل به این صورت عمل می‌کند: فرض کنید آلیس می‌خواهد ۱۱٫۷ بیت‌کوین، یا BTC، برای باب بفرستد. آلیس ابتدا در میان UTXOهای موجودی که مالک آن‌هاست، مجموعه‌ای را پیدا می‌کند که ارزش مجموعشان دست‌کم ۱۱٫۷ BTC باشد. در عمل احتمالاً آلیس نمی‌تواند مجموعه‌ای با ارزش دقیقاً ۱۱٫۷ BTC پیدا کند. فرض کنیم کوچک‌ترین مجموعه‌ای که در اختیار دارد برابر است با:

۶ + ۴ + ۲ = ۱۲ BTC

سپس آلیس تراکنشی با همین سه ورودی و دو خروجی ایجاد می‌کند. خروجی نخست ۱۱٫۷ BTC ارزش دارد و مالک آن نشانی باب است. خروجی دوم، ۰٫۳ BTC باقی‌مانده را به‌عنوان «باقی‌پول» به خود آلیس بازمی‌گرداند؛ بنابراین مالک این خروجی، خود آلیس خواهد بود.

استخراج

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

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

در چارچوب این الگو، الگوریتم بررسی اعتبار یک بلوک چنین است:

۱. بررسی کن که بلوک پیشینی که بلوک فعلی به آن ارجاع می‌دهد، وجود داشته و معتبر باشد.

۲. بررسی کن که برچسب زمانی بلوک از برچسب زمانی بلوک قبلی بیشتر باشد [۲] و بیش از دو ساعت در آینده قرار نگیرد.

۳. بررسی کن که اثبات کارِ بلوک معتبر باشد.

۴. فرض کن S[0] وضعیت سامانه در پایان بلوک قبلی است.

۵. فرض کن TX فهرست تراکنش‌های بلوک و شامل n تراکنش است. برای هر i در بازهٔ 0…n−1، مقدار زیر را تعیین کن:

S[i+1] = APPLY(S[i], TX[i])

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

۶. مقدار «درست» را برگردان و S[n] را به‌عنوان وضعیت سامانه در پایان این بلوک ثبت کن.

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

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

از میان شروط اعتباری که در فهرست بالا آمده‌اند، تنها شرطی که در سامانه‌های دیگر دیده نمی‌شود، الزام «اثبات کار» است. شرط دقیق این است که هش دوگانهٔ SHA-256 هر بلوک، هنگامی که به‌صورت یک عدد ۲۵۶ بیتی در نظر گرفته می‌شود، باید از هدفی که به‌طور پویا تنظیم می‌شود کمتر باشد. در زمان نگارش متن، این هدف تقریباً برابر با ۲^۱۸۷ است.

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

هدف این شرط آن است که ایجاد بلوک از نظر محاسباتی «دشوار» شود و در نتیجه، مهاجمان سیبیل نتوانند کل زنجیرهٔ بلوکی را به سود خود از نو بسازند. SHA-256 طوری طراحی شده است که تابعی شبه‌تصادفی و کاملاً پیش‌بینی‌ناپذیر باشد. بنابراین تنها راه ایجاد یک بلوک معتبر، آزمون‌وخطاست: استخراج‌کننده باید نانس را بارها افزایش دهد و هر بار بررسی کند که آیا هش جدید با شرط تعیین‌شده مطابقت دارد یا نه.

با هدف فعلیِ تقریباً ۲^۱۸۷، شبکه باید به‌طور متوسط حدود ۲^۶۹ بار تلاش کند تا یک بلوک معتبر پیدا شود. به‌طور کلی، شبکه پس از هر ۲۰۱۶ بلوک، هدف را دوباره تنظیم می‌کند تا به‌طور میانگین هر ده دقیقه یکی از گره‌های شبکه یک بلوک جدید تولید کند.

برای جبران این کار محاسباتی، استخراج‌کنندهٔ هر بلوک حق دارد تراکنشی را در آن بلوک بگنجاند که ۲۵ BTC را از هیچ به خودش اختصاص می‌دهد. افزون بر این، اگر مجموع ارزش اسمی ورودی‌های یک تراکنش از مجموع ارزش اسمی خروجی‌های آن بیشتر باشد، تفاوت این دو مقدار نیز به‌عنوان «کارمزد تراکنش» به استخراج‌کننده می‌رسد. در ضمن، این سازوکار تنها راهی است که BTC از طریق آن منتشر می‌شود؛ وضعیت پیدایش در آغاز هیچ سکه‌ای نداشت.

هدف استخراج در برابر حمله

برای درک بهتر هدف استخراج، باید دید در صورت حضور یک مهاجم مخرب چه اتفاقی می‌افتد. از آنجا که امنیت رمزنگاری زیربنایی بیت‌کوین شناخته‌شده است، مهاجم بخشی از سامانهٔ بیت‌کوین را هدف می‌گیرد که مستقیماً با رمزنگاری محافظت نمی‌شود: ترتیب تراکنش‌ها.

راهبرد مهاجم ساده است:

۱. در ازای دریافت یک محصول، ۱۰۰ BTC برای یک فروشنده بفرستد؛ ترجیحاً محصولی دیجیتال که به‌سرعت تحویل داده می‌شود.

۲. منتظر بماند تا محصول تحویل داده شود.

۳. تراکنش دیگری ایجاد کند که همان ۱۰۰ BTC را به خودش می‌فرستد.

۴. تلاش کند شبکه را متقاعد کند که تراکنشِ ارسال پول به خودش، زودتر از تراکنش پرداخت به فروشنده انجام شده است.

پس از انجام مرحلهٔ (۱)، …

پس از انجام تراکنش، چند دقیقه بعد یکی از استخراج‌کنندگان آن را در یک بلوک، مثلاً بلوک شمارهٔ ۲۷۰۰۰۰، قرار می‌دهد. حدود یک ساعت بعد، پنج بلوک دیگر پس از آن به زنجیره افزوده شده‌اند. هر یک از این بلوک‌ها به‌طور غیرمستقیم به تراکنش اشاره می‌کند و به این ترتیب آن را «تأیید» می‌کند. در این مرحله، فروشنده پرداخت را نهایی‌شده می‌پذیرد و محصول را تحویل می‌دهد. از آنجا که فرض بر این است که محصول دیجیتال است، تحویل آن فوراً انجام می‌شود.

اکنون مهاجم تراکنش دیگری ایجاد می‌کند که همان ۱۰۰ بیت‌کوین را برای خودش می‌فرستد. اگر مهاجم صرفاً این تراکنش را در شبکه منتشر کند، تراکنش پردازش نخواهد شد. استخراج‌کنندگان می‌کوشند تابع APPLY(S, TX) را اجرا کنند و متوجه می‌شوند که TX یک UTXO، یعنی «خروجی خرج‌نشدهٔ تراکنش»، را مصرف می‌کند که دیگر در وضعیت کنونی وجود ندارد.

بنابراین، مهاجم به‌جای انتشار عادی تراکنش، یک «انشعاب» یا فورک از زنجیرهٔ بلوکی ایجاد می‌کند. او کار را با استخراج نسخه‌ای دیگر از بلوک ۲۷۰۰۰۰ آغاز می‌کند؛ این نسخه نیز مانند نسخهٔ اصلی، بلوک ۲۶۹۹۹۹ را به‌عنوان والد خود معرفی می‌کند، اما به‌جای تراکنش قبلی، تراکنش جدید را در خود دارد. چون داده‌های بلوک تغییر کرده است، مهاجم باید اثبات کار را دوباره انجام دهد. افزون بر این، نسخهٔ جدید بلوک ۲۷۰۰۰۰ که مهاجم ساخته، هش متفاوتی دارد. در نتیجه، بلوک‌های اصلی ۲۷۰۰۰۱ تا ۲۷۰۰۰۵ به آن «اشاره» نمی‌کنند و زنجیرهٔ اصلی و زنجیرهٔ تازهٔ مهاجم کاملاً از یکدیگر جدا می‌شوند.

قاعده این است که هنگام بروز انشعاب، طولانی‌ترین زنجیرهٔ بلوکی حقیقت در نظر گرفته می‌شود. ازاین‌رو، استخراج‌کنندگان مشروع کار خود را روی زنجیره‌ای ادامه می‌دهند که به بلوک ۲۷۰۰۰۵ رسیده است، در حالی که مهاجم به‌تنهایی روی زنجیرهٔ خود از بلوک ۲۷۰۰۰۰ کار می‌کند. مهاجم برای اینکه زنجیرهٔ بلوکی خودش را به طولانی‌ترین زنجیره تبدیل کند، باید قدرت محاسباتی بیشتری از مجموع قدرت محاسباتی تمام بخش‌های دیگر شبکه داشته باشد تا بتواند عقب‌ماندگی خود را جبران کند؛ اصطلاح «حملهٔ ۵۱ درصدی» نیز از همین‌جا می‌آید.

درخت‌های مرکل

سمت چپ: برای اثبات معتبر بودن یک شاخه، کافی است تنها تعداد اندکی از گره‌های درخت مرکل ارائه شود.

سمت راست: هر تلاشی برای تغییر دادن هر بخشی از درخت مرکل، سرانجام در نقطه‌ای بالاتر از زنجیره به ناسازگاری منجر خواهد شد.

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

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

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

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

می‌توان گفت پروتکل درخت مرکل برای پایداری بلندمدت ضروری است. تا آوریل ۲۰۱۴، یک «گرهٔ کامل» در شبکهٔ بیت‌کوین، یعنی گرهی که تمام محتوای تک‌تک بلوک‌ها را ذخیره و پردازش می‌کند، حدود ۱۵ گیگابایت فضای دیسک اشغال می‌کرد. این میزان هر ماه بیش از یک گیگابایت افزایش می‌یافت. در آن زمان، اجرای گرهٔ کامل برای برخی رایانه‌های رومیزی امکان‌پذیر بود، اما برای تلفن‌های همراه نه؛ و در آینده‌ای دورتر، فقط کسب‌وکارها و علاقه‌مندان جدی خواهند توانست در این سطح مشارکت کنند.

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

کاربردهای جایگزین زنجیرهٔ بلوکی

استفاده از ایدهٔ زیربنایی زنجیرهٔ بلوکی برای مفاهیم دیگر نیز سابقه‌ای طولانی دارد. نیک سابو در سال ۲۰۰۵ مفهوم «اسناد مالکیت امن با اختیار مالک» را مطرح کرد. او در سندی توضیح داد که چگونه «پیشرفت‌های تازه در فناوری پایگاه‌های دادهٔ تکثیرشده» می‌تواند امکان ایجاد سامانه‌ای مبتنی بر زنجیرهٔ بلوکی را فراهم کند که مشخص کند هر قطعه زمین در مالکیت چه کسی است. طرح او چارچوبی مفصل داشت و مفاهیمی مانند تصاحب زمین بی‌مالک از راه سکونت و آبادانی، تملک زمین از طریق تصرف معارض و مالیات زمین به شیوهٔ جورجیستی را نیز در بر می‌گرفت. بااین‌همه، در آن زمان هیچ سامانهٔ پایگاه دادهٔ تکثیرشدهٔ کارآمدی وجود نداشت و به همین دلیل این پروتکل هرگز در عمل پیاده‌سازی نشد. اما پس از سال ۲۰۰۹، با شکل‌گیری سازوکار اجماع غیرمتمرکز بیت‌کوین، کاربردهای جایگزین متعددی به‌سرعت پدیدار شدند.

نیم‌کوین: نیم‌کوین که در سال ۲۰۱۰ ساخته شد، در دقیق‌ترین توصیف یک پایگاه دادهٔ غیرمتمرکز برای ثبت نام‌هاست. در پروتکل‌های غیرمتمرکزی مانند تور، بیت‌کوین و بیت‌مسیج، باید راهی برای شناسایی حساب‌ها وجود داشته باشد تا دیگران بتوانند با صاحبان آن‌ها تعامل کنند. بااین‌حال، در تمام راه‌حل‌های موجود، تنها شناسهٔ در دسترس یک هش شبه‌تصادفی مانند 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy است.

در حالت ایدئال، هر فرد ترجیح می‌دهد حسابی با نامی مانند «george» داشته باشد. مشکل اینجاست که اگر یک نفر بتواند حسابی با نام «george» ایجاد کند، شخص دیگری نیز می‌تواند با همان فرایند این نام را برای خود ثبت کند و خود را به‌جای فرد نخست جا بزند. تنها راه‌حل، اجرای قاعدهٔ «تقدم با نخستین ثبت‌کننده است»

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

سکه‌های رنگی

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

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

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

متاکوین‌ها

ایده متاکوین این است که پروتکلی روی بیت‌کوین قرار گیرد و از تراکنش‌های بیت‌کوین برای ذخیره تراکنش‌های متاکوین استفاده کند، اما تابع گذار حالت متفاوتی به نام APPLY′ داشته باشد. پروتکل متاکوین نمی‌تواند مانع درج تراکنش‌های نامعتبر متاکوین در زنجیره بلوکی بیت‌کوین شود. ازاین‌رو، قاعده‌ای به آن افزوده می‌شود که بر اساس آن، اگر APPLY′(S,TX) خطا برگرداند، پروتکل به‌طور پیش‌فرض حالت را بدون تغییر باقی می‌گذارد؛ یعنی:

APPLY′(S,TX) = S

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

دو رویکرد ساخت پروتکل اجماع

به‌طور کلی، برای ساخت پروتکل اجماع دو راه وجود دارد: نخست، ایجاد شبکه‌ای مستقل؛ و دوم، ساخت پروتکلی روی بیت‌کوین.

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

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

در مقابل، رویکرد مبتنی بر بیت‌کوین یک نقص اساسی دارد: قابلیت‌های «تأیید ساده پرداخت» بیت‌کوین، یا SPV، به پروتکل‌های ساخته‌شده روی آن به ارث نمی‌رسد. SPV در بیت‌کوین کار می‌کند، زیرا می‌تواند عمق یک تراکنش در زنجیره بلوکی را معیاری تقریبی برای اعتبار آن در نظر بگیرد. وقتی تراکنش‌های پیشین و اجداد یک تراکنش به‌اندازه کافی در گذشته زنجیره قرار گرفته باشند، می‌توان با اطمینان گفت که آن تراکنش‌ها به‌طور مشروع بخشی از وضعیت شبکه بوده‌اند.

اما متاپروتکل‌های مبتنی بر زنجیره بلوکی نمی‌توانند زنجیره اصلی را وادار کنند تراکنش‌هایی را که در چارچوب قواعد خودشان نامعتبرند نپذیرد. بنابراین، پیاده‌سازی کاملاً امن SPV برای یک متاپروتکل باید زنجیره بلوکی بیت‌کوین را تا نقطه آغاز آن به عقب جست‌وجو کند تا مشخص شود تراکنش‌های مورد نظر معتبرند یا نه.

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

اسکریپت‌نویسی و قراردادهای هوشمند

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

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

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

از اسکریپت‌ها می‌توان برای پرداخت جایزه به کسانی استفاده کرد که مسائل محاسباتی را حل می‌کنند. حتی می‌توان اسکریپتی با چنین مضمونی ساخت: «اگر بتوانید مدرکی مبتنی بر SPV ارائه دهید که نشان دهد یک تراکنش دوج‌کوین به مبلغ تعیین‌شده برای من فرستاده‌اید، این خروجی خرج‌نشده بیت‌کوین متعلق به شماست.» چنین سازوکاری عملاً مبادله غیرمتمرکز میان رمزارزهای مختلف را امکان‌پذیر می‌کند.

با وجود این قابلیت‌ها، زبان اسکریپت‌نویسی بیت‌کوین در شکل پیاده‌سازی‌شده خود چند محدودیت مهم دارد:

کامل نبودن از نظر تورینگ

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

از نظر نظری، برنامه‌نویسان اسکریپت می‌توانند بر این مانع غلبه کنند، زیرا هر حلقه را می‌توان با تکرار چندباره کد زیرین و استفاده از یک دستور شرطی شبیه‌سازی کرد. بااین‌حال، چنین روشی اسکریپت‌هایی تولید می‌کند که از نظر مصرف فضا بسیار ناکارآمدند. برای مثال، پیاده‌سازی یک الگوریتم جایگزین برای امضای منحنی بیضوی احتمالاً مستلزم آن است که ۲۵۶ دور ضرب تکراری، هریک به‌طور جداگانه، در کد گنجانده شود.

بی‌اطلاعی از مقدار

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

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

یکی از کاربردهای قدرتمند قرارداد اوراکل، قرارداد پوشش ریسک است. در چنین قراردادی، A و B هرکدام مقداری بیت‌کوین به ارزش ۱۰۰۰ دلار وارد قرارداد می‌کنند. پس از ۳۰ روز، اسکریپت مقداری بیت‌کوین به ارزش ۱۰۰۰ دلار برای A می‌فرستد و باقی‌مانده را به B می‌دهد. اجرای این قرارداد به اوراکلی نیاز دارد که ارزش یک بیت‌کوین را بر حسب دلار تعیین کند؛ با وجود این، چنین راهکاری از نظر اعتماد موردنیاز و الزامات زیرساختی، پیشرفتی عظیم در مقایسه با راه‌حل‌های کاملاً متمرکز موجود به شمار می‌آید.

اما خروجی‌های خرج‌نشده تراکنش یا UTXOها ماهیتی «همه یا هیچ» دارند. ازاین‌رو، تنها راه اجرای چنین قراردادی استفاده از ترفندی بسیار ناکارآمد است: باید تعداد زیادی UTXO با مبالغ گوناگون ایجاد شود؛ برای مثال، به‌ازای هر k تا ۳۰، یک UTXO با مقدار ۲^k وجود داشته باشد. سپس اوراکل تصمیم می‌گیرد کدام UTXOها به A و کدام‌یک به B فرستاده شوند.

محدودیت‌های UTXO

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

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

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

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

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

اتریوم؛ لایه‌ای بنیادی برای برنامه‌های غیرمتمرکز

هدف اتریوم ایجاد پروتکلی جایگزین برای ساخت برنامه‌های غیرمتمرکز است. این پروتکل مجموعه متفاوتی از موازنه‌ها را ارائه می‌دهد که به باور طراحان آن، برای طیف گسترده‌ای از برنامه‌های غیرمتمرکز بسیار مفید خواهد بود. تأکید ویژه اتریوم بر موقعیت‌هایی است که در آن‌ها توسعه سریع، تأمین امنیت برنامه‌های کوچک و کم‌استفاده، و تعامل بسیار کارآمد میان برنامه‌های مختلف اهمیت دارد.

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

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

حساب‌های اتریوم

حالت در اتریوم از اشیایی به نام «حساب» تشکیل می‌شود. هر حساب یک نشانی ۲۰ بایتی دارد و انتقال حالت از طریق جابه‌جایی مستقیم ارزش و اطلاعات میان حساب‌ها انجام می‌شود. هر حساب اتریوم چهار بخش دارد:

نانس: شمارنده‌ای که تضمین می‌کند هر تراکنش فقط یک بار پردازش شود؛

موجودی فعلی اتر حساب؛

کد قرارداد حساب، در صورتی که چنین کدی وجود داشته باشد؛

فضای ذخیره‌سازی حساب، که به‌طور پیش‌فرض خالی است.

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

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

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

پیام‌ها و تراکنش‌ها

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

گیرنده پیام؛

امضایی که هویت فرستنده را مشخص می‌کند؛

مقدار اتری که باید از فرستنده به گیرنده منتقل شود؛

یک میدان داده اختیاری؛

مقدار STARTGAS که حداکثر تعداد گام‌های محاسباتی مجاز برای اجرای تراکنش را نشان می‌دهد؛

مقدار GASPRICE که کارمزد پرداختی فرستنده به‌ازای هر گام محاسباتی را تعیین می‌کند.

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

قرارداد می‌تواند به داده‌های همراه تراکنش دسترسی پیدا کند. برای نمونه، اگر قراردادی نقش یک سرویس ثبت دامنه روی زنجیره بلوکی را داشته باشد، ممکن است داده‌های دریافتی را شامل دو «فیلد» در نظر بگیرد: فیلد نخست، دامنه‌ای است که باید ثبت شود و فیلد دوم، نشانی IP است که آن دامنه باید برایش ثبت شود. قرارداد این مقادیر را از داده‌های پیام می‌خواند و به‌شکل مناسب در فضای ذخیره‌سازی خود قرار می‌دهد.

فیلدهای STARTGAS و GASPRICE نقشی حیاتی در سازوکار اتریوم برای مقابله با حملات منع سرویس دارند. برای جلوگیری از حلقه‌های بی‌نهایتِ ناخواسته یا مخرب و نیز دیگر شکل‌های اتلاف منابع محاسباتی در کد، هر تراکنش باید سقفی برای تعداد گام‌های محاسباتی قابل استفاده در اجرای کد تعیین کند. واحد بنیادی محاسبات «گس» یا Gas نام دارد. هر گام محاسباتی معمولاً ۱ گس هزینه دارد، اما هزینه گس بعضی عملیات بیشتر است؛ زیرا اجرای آن‌ها به توان محاسباتی بیشتری نیاز دارد یا میزان داده‌ای را افزایش می‌دهد که باید به‌عنوان بخشی از وضعیت شبکه ذخیره شود. علاوه بر این، به‌ازای هر بایت از داده‌های تراکنش نیز ۵ گس دریافت می‌شود.

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

پیام‌ها

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

فرستنده پیام که به‌طور ضمنی مشخص می‌شود؛

گیرنده پیام؛

مقدار اتر انتقال‌یافته همراه پیام؛

یک فیلد اختیاری برای داده؛

یک مقدار STARTGAS.

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

باید توجه داشت که سهمیه گسی که یک تراکنش یا قرارداد تعیین می‌کند، بر مجموع گس مصرف‌شده در همان تراکنش و تمام اجراهای فرعی آن اعمال می‌شود. برای مثال، فرض کنید عامل خارجی A تراکنشی با ۱۰۰۰ گس برای B می‌فرستد. اگر B پیش از ارسال پیامی به C مقدار ۶۰۰ گس مصرف کند و اجرای داخلی C نیز پیش از بازگشت ۳۰۰ گس دیگر مصرف کند، B فقط می‌تواند ۱۰۰ گس دیگر خرج کند و پس از آن گسش به پایان می‌رسد.

تابع انتقال وضعیت اتریوم

تابع انتقال وضعیت اتریوم را می‌توان به‌صورت زیر تعریف کرد:

APPLY(S, TX) → S′

این تابع طبق مراحل زیر عمل می‌کند:

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

کارمزد تراکنش با فرمول STARTGAS × GASPRICE محاسبه می‌شود و نشانی فرستنده نیز از روی امضا به دست می‌آید. سپس کارمزد از موجودی حساب فرستنده کسر و نانس فرستنده یک واحد افزایش داده می‌شود. اگر موجودی حساب برای پرداخت این مبلغ کافی نباشد، تابع خطا برمی‌گرداند.

مقدار GAS برابر با STARTGAS قرار داده می‌شود. سپس برای پرداخت هزینه بایت‌های موجود در تراکنش، به‌ازای هر بایت مقدار معینی گس از آن کسر می‌شود.

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

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

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

در غیر این صورت، کارمزد مربوط به تمام گس باقی‌مانده به فرستنده بازپرداخت می‌شود و کارمزدی که بابت گس مصرف‌شده پرداخت شده است به استخراج‌کننده می‌رسد.

نمونه‌ای از اجرای انتقال وضعیت

برای مثال، فرض کنید کد قرارداد چنین باشد:

در عمل، کد قرارداد با کد سطح‌پایین ماشین مجازی اتریوم، یا EVM، نوشته می‌شود. بااین‌حال، برای روشن‌تر بودن مثال، کد مورد نظر با Serpent، یکی از زبان‌های سطح‌بالای اتریوم، نوشته شده است و می‌توان آن را به کد EVM کامپایل کرد.

فرض کنید فضای ذخیره‌سازی قرارداد در آغاز خالی است. تراکنشی ارسال می‌شود که مقدار آن ۱۰ اتر است، ۲۰۰۰ گس در اختیار دارد، قیمت هر گس یا GASPRICE آن ۰٫۰۰۱ اتر است و ۶۴ بایت داده به همراه دارد. بایت‌های ۰ تا ۳۱ نمایانگر عدد ۲ هستند و بایت‌های ۳۲ تا ۶۳ رشته CHARLIE fn3 را نشان می‌دهند. در این حالت، تابع انتقال وضعیت مراحل زیر را طی می‌کند:

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

بررسی می‌شود که فرستنده تراکنش دست‌کم حاصل‌ضرب ۲۰۰۰ × ۰٫۰۰۱، یعنی ۲ اتر، در حساب خود داشته باشد. اگر موجودی کافی باشد، ۲ اتر از حساب فرستنده کسر می‌شود.

مقدار گس در آغاز برابر با ۲۰۰۰ قرار می‌گیرد. اگر فرض کنیم طول تراکنش ۱۷۰ بایت و هزینه هر بایت ۵ گس باشد، ۸۵۰ گس کسر می‌شود و در نتیجه ۱۱۵۰ گس باقی می‌ماند.

سپس ۱۰ اتر دیگر از حساب فرستنده کسر و به حساب قرارداد افزوده می‌شود.

کد قرارداد اجرا می‌شود. در این نمونه، عملیات ساده است: کد بررسی می‌کند که آیا محل ذخیره‌سازی قرارداد در شاخص ۲ قبلاً استفاده شده است یا نه. کد متوجه می‌شود که این محل هنوز استفاده نشده و بنابراین مقدار CHARLIE را در شاخص ۲ ذخیره می‌کند. فرض کنید این عملیات ۱۸۷ گس مصرف کند. در این صورت، مقدار گس باقی‌مانده برابر است با:

۱۱۵۰ − ۱۸۷ = ۹۶۳

در پایان، حاصل‌ضرب ۹۶۳ × ۰٫۰۰۱، یعنی ۰٫۹۶۳ اتر، دوباره به حساب فرستنده افزوده می‌شود و تابع، وضعیت حاصل را برمی‌گرداند.

اگر در سمت گیرنده تراکنش هیچ قراردادی وجود نداشت، کل کارمزد تراکنش صرفاً برابر بود با GASPRICE ارائه‌شده، ضرب‌در طول تراکنش برحسب بایت. در چنین وضعی، داده‌ای که همراه تراکنش فرستاده شده بود اهمیتی نداشت.

از نظر بازگرداندن تغییرات، پیام‌ها همانند تراکنش‌ها عمل می‌کنند. اگر هنگام اجرای یک پیام گس تمام شود، تغییرات حاصل از اجرای همان پیام و تمام اجراهای دیگری که آن پیام به راه انداخته است بازگردانده می‌شوند؛ بااین‌حال، لازم نیست اجراهای والد نیز به وضعیت پیشین بازگردند. این ویژگی به آن معناست که یک قرارداد می‌تواند با اطمینان نسبی قرارداد دیگری را فراخوانی کند: اگر A قرارداد B را با G واحد گس فرا بخواند، تضمین می‌شود که اجرای A حداکثر همان G واحد گس را از دست خواهد داد.

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

اجرای کد

کد قراردادهای اتریوم با یک زبان بایت‌کد سطح‌پایین و مبتنی بر پشته نوشته می‌شود که «کد ماشین مجازی اتریوم» یا «کد EVM» نام دارد. این کد از رشته‌ای از بایت‌ها تشکیل شده است و هر بایت نماینده یک عملیات است. اجرای کد را می‌توان، در حالت کلی، حلقه‌ای بی‌پایان دانست: عملیاتی که شمارنده برنامه در لحظه جاری به آن اشاره می‌کند اجرا می‌شود؛ شمارنده برنامه که مقدار اولیه‌اش صفر است، سپس یک واحد افزایش می‌یابد؛ و این روند تا زمانی ادامه پیدا می‌کند که اجرای برنامه به انتهای کد برسد یا با خطا، دستور STOP یا دستور RETURN روبه‌رو شود.

عملیات‌ها برای ذخیره داده به سه نوع فضا دسترسی دارند:

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

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

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

کد همچنین می‌تواند به مبلغ یا مقدار پیام ورودی، فرستنده آن، داده‌های همراه پیام و اطلاعات سرآیند بلوک دسترسی داشته باشد.

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

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

(block_state, transaction, message, code, memory, stack, pc, gas)

در این چندتایی، block_state وضعیت سراسری است که همه حساب‌ها را در بر می‌گیرد و موجودی‌ها و داده‌های ذخیره‌شده را نیز شامل می‌شود. در آغاز هر دور اجرا، دستور جاری با انتخاب بایت pcام از code پیدا می‌شود؛ اگر pc >= len(code) باشد، مقدار صفر در نظر گرفته می‌شود. تعریف هر دستور نیز مشخص می‌کند که آن دستور چگونه این چندتایی را تغییر می‌دهد.

برای مثال، دستور ADD دو مورد را از بالای پشته برمی‌دارد و مجموع آن‌ها را دوباره روی پشته قرار می‌دهد، مقدار گس را یک واحد کاهش می‌دهد و pc را یک واحد افزایش می‌دهد. دستور SSTORE نیز دو مورد بالای پشته را برمی‌دارد و مورد دوم را در فضای ذخیره‌سازی قرارداد، در شاخصی که مورد اول مشخص می‌کند، قرار می‌دهد. با آنکه برای بهینه‌سازی اجرای ماشین مجازی اتریوم از طریق کامپایل درجا یا «Just-in-Time Compilation» روش‌های فراوانی وجود دارد، یک پیاده‌سازی پایه‌ای از اتریوم را می‌توان تنها با چند صد خط کد ساخت.

بلاک‌چین و استخراج

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

الگوریتم پایه اعتبارسنجی بلوک در اتریوم به‌ترتیب زیر عمل می‌کند:

بررسی کنید که بلوک قبلیِ مورد ارجاع وجود داشته باشد و معتبر باشد.

بررسی کنید که برچسب زمانی بلوک از برچسب زمانی بلوک قبلیِ مورد ارجاع بزرگ‌تر باشد و بیش از ۱۵ دقیقه در آینده قرار نداشته باشد.

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

بررسی کنید که اثبات کار بلوک معتبر باشد.

فرض کنید S[0] وضعیت موجود در پایان بلوک قبلی است.

فرض کنید TX فهرست تراکنش‌های بلوک است و n تراکنش دارد. برای تمام مقادیر i در بازه 0…n-1، رابطه زیر را اعمال کنید:

S[i+1] = APPLY(S[i], TX[i])

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

S_FINAL را برابر S[n] در نظر بگیرید، با این تفاوت که پاداش بلوکی پرداخت‌شده به استخراج‌کننده نیز به آن افزوده می‌شود.

بررسی کنید که آیا ریشه درخت مرکلِ وضعیت S_FINAL با ریشه وضعیت نهاییِ درج‌شده در سرآیند بلوک برابر است یا نه. اگر این دو برابر باشند، بلوک معتبر است؛ در غیر این صورت، بلوک اعتبار ندارد.

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

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

یکی از پرسش‌های رایج این است که کد قرارداد، از نظر سخت‌افزار فیزیکی، دقیقاً «کجا» اجرا می‌شود. پاسخ ساده است: فرایند اجرای کد قرارداد بخشی از تعریف تابع انتقال وضعیت به شمار می‌آید و این تابع نیز جزئی از الگوریتم اعتبارسنجی بلوک است. بنابراین، اگر تراکنشی به بلوک B افزوده شود، اجرای کدی که آن تراکنش به راه می‌اندازد به‌وسیله همه گره‌هایی انجام خواهد شد که بلوک B را دانلود و اعتبارسنجی می‌کنند؛ چه گره‌هایی که اکنون این کار را انجام می‌دهند و چه گره‌هایی که در آینده آن بلوک را دریافت و بررسی خواهند کرد.

کاربردها

کاربردهایی که بر بستر اتریوم ساخته می‌شوند، به‌طور کلی در سه دسته قرار می‌گیرند.

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

دسته دوم، کاربردهای نیمه‌مالی است. در این کاربردها پول نقش دارد، اما بخش مهمی از کاری که انجام می‌شود ماهیتی غیرپولی دارد. نمونه‌ای کامل از این نوع کاربرد، پاداش‌هایی است که برای ارائه راه‌حل مسائل محاسباتی تعیین می‌شوند و سازوکار اجرای خودکار دارند.

دسته سوم شامل کاربردهایی مانند رأی‌گیری آنلاین و حکمرانی غیرمتمرکز است که اساساً هیچ ماهیت مالی ندارند.

سامانه‌های توکن

سامانه‌های توکن روی زنجیره

سامانه‌های توکنی که روی بلاک‌چین اجرا می‌شوند کاربردهای فراوانی دارند. این کاربردها از ایجاد ارزهای فرعیِ نماینده دارایی‌هایی مانند دلار آمریکا یا طلا آغاز می‌شود و سهام شرکت‌ها، توکن‌های منفردِ نماینده دارایی هوشمند، کوپن‌های امن و جعل‌ناپذیر و حتی سامانه‌های توکنی‌ای را در بر می‌گیرد که هیچ ارتباطی با ارزش‌های متعارف ندارند و صرفاً به‌عنوان نظام امتیازدهی برای ایجاد انگیزه به کار می‌روند.

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

کد پایه برای پیاده‌سازی چنین سامانه‌ای با زبان سرپنت (Serpent) به شکل زیر است:

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

از نظر نظری، سامانه‌های توکنی مبتنی بر اتریوم که نقش ارز فرعی را دارند، می‌توانند قابلیت مهم دیگری نیز ارائه کنند؛ قابلیتی که فراارزهای مبتنی بر بیت‌کوین و ثبت‌شده روی زنجیره فاقد آن هستند: امکان پرداخت مستقیم کارمزد تراکنش با همان ارز فرعی.

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

مشتقات مالی و ارزهای دارای ارزش باثبات

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

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

با فراهم‌شدن این جزء حیاتی، قرارداد پوشش ریسک می‌تواند به ترتیب زیر عمل کند:

منتظر بماند تا طرف A مبلغ ۱۰۰۰ اتر وارد قرارداد کند.

منتظر بماند تا طرف B نیز ۱۰۰۰ اتر وارد قرارداد کند.

ارزش دلاری ۱۰۰۰ اتر را با استعلام از قرارداد خوراک داده محاسبه و در حافظه قرارداد ثبت کند؛ فرض کنیم این مبلغ x دلار باشد.

پس از ۳۰ روز، به A یا B اجازه دهد قرارداد را «دوباره فعال» کند. در این مرحله، قرارداد بار دیگر برای دریافت قیمت تازه به خوراک داده مراجعه می‌کند، معادل x دلار اتر را بر اساس قیمت جدید برای A می‌فرستد و باقی‌مانده اتر را به B می‌دهد.

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

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

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

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

سامانه‌های هویت و اعتبار

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

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

مهم‌ترین کاربردی که برای این سامانه مطرح شده، ایجاد یک سامانه DNS یا «سامانه نام دامنه» است. چنین سامانه‌ای نام دامنه‌ای مانند «bitcoin.org» یا در مورد نیم‌کوین، «bitcoin.bit» را به یک نشانی IP نگاشت می‌کند. کاربردهای دیگر آن شامل احراز اصالت ایمیل و، در آینده، سامانه‌های پیشرفته‌تر اعتبارسنجی است.

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

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

ذخیره‌سازی غیرمتمرکز فایل

در چند سال گذشته، چندین استارتاپ محبوب برای ذخیره‌سازی آنلاین فایل پدید آمده‌اند که در میان آن‌ها دراپ‌باکس برجسته‌تر از بقیه است. این خدمات می‌کوشند به کاربران امکان دهند نسخه‌ای پشتیبان از دیسک سخت خود بارگذاری کنند؛ سرویس آن نسخه را نگه می‌دارد و در برابر دریافت مبلغی ماهانه، دسترسی به آن را در اختیار کاربر قرار می‌دهد. بااین‌حال، بازار کنونی ذخیره‌سازی فایل گاهی نسبتاً ناکارآمد است. نگاهی گذرا به راهکارهای موجود نشان می‌دهد که هزینه‌های ماهانه خدمات رایج ذخیره‌سازی فایل، به‌ویژه در محدوده نامتعارف ۲۰ تا ۲۰۰ گیگابایت، چنان بالاست که کاربر ممکن است تنها طی یک ماه بیش از بهای یک دیسک سخت کامل پول بپردازد. این محدوده از آن جهت نامتعارف است که نه سهمیه‌های رایگان آن را پوشش می‌دهند و نه تخفیف‌های ویژه مشتریان سازمانی شامل حال آن می‌شوند.

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

جزء زیربنایی و کلیدی چنین سازوکاری چیزی است که «قرارداد غیرمتمرکز دراپ‌باکس» نامیده شده است. این قرارداد به شیوه زیر کار می‌کند. ابتدا داده موردنظر به بلوک‌هایی تقسیم می‌شود؛ هر بلوک برای حفظ حریم خصوصی رمزگذاری می‌شود و سپس از مجموعه بلوک‌ها یک درخت مرکل ساخته می‌شود. پس از آن، قراردادی با این قاعده ایجاد می‌شود که در هر N بلوک، یک شاخص را به‌طور تصادفی از درخت مرکل انتخاب کند. قرارداد برای تولید تصادف از هش بلوک قبلی استفاده می‌کند که کد قرارداد به آن دسترسی دارد. سپس X اتر به نخستین نهادی پرداخت می‌شود که تراکنشی حاوی اثبات مالکیت بلوک واقع در همان شاخص مشخص درخت ارائه دهد؛ این اثبات شبیه «تأیید ساده‌شده پرداخت» است.

هرگاه کاربر بخواهد فایل خود را دوباره بارگیری کند، می‌تواند برای بازیابی آن از پروتکل کانال پرداخت خرد استفاده کند؛ برای مثال، به‌ازای هر ۳۲ کیلوبایت، ۱ سابو بپردازد. روشی که کمترین کارمزد را تحمیل می‌کند این است که پرداخت‌کننده تا پایان کار تراکنش را منتشر نکند. در عوض، پس از دریافت هر ۳۲ کیلوبایت، همان تراکنش را با تراکنش دیگری جایگزین کند که همان نانس را دارد، اما مبلغ پرداختی آن اندکی بیشتر است.

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

سازمان‌های خودگردان غیرمتمرکز

مفهوم کلی «سازمان خودگردان غیرمتمرکز» یا DAO به یک موجودیت مجازی اشاره دارد که مجموعه مشخصی از اعضا یا سهام‌داران را در بر می‌گیرد. این افراد، شاید با کسب اکثریتی ۶۷ درصدی، حق دارند وجوه آن موجودیت را خرج کنند یا کد آن را تغییر دهند. اعضا به‌صورت جمعی تصمیم می‌گیرند که سازمان منابع مالی خود را چگونه تخصیص دهد.

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

بخش بزرگی از بحث‌های مطرح‌شده درباره DAOها تا اینجا بر الگوی «سرمایه‌دارانه» یک «شرکت خودگردان غیرمتمرکز» یا DAC متمرکز بوده است؛ الگویی که در آن سهام‌داران سود سهام دریافت می‌کنند و سهام نیز قابل معامله است. گزینه جایگزین را شاید بتوان «اجتماع خودگردان غیرمتمرکز» نامید. در این الگو، همه اعضا سهمی برابر در تصمیم‌گیری دارند و برای افزودن یا حذف یک عضو، موافقت ۶۷ درصد اعضای موجود لازم است. در آن صورت، گروه باید به‌صورت جمعی این قاعده را نیز اجرا کند که هر فرد فقط حق داشتن یک عضویت را دارد.

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

در یک پیاده‌سازی ساده از چنین قرارداد DAO، سه نوع تراکنش وجود دارد که بر اساس داده‌های ارائه‌شده در تراکنش از یکدیگر تشخیص داده می‌شوند:

[0,i,K,V] برای ثبت پیشنهادی با شاخص i که می‌خواهد نشانی موجود در شاخص ذخیره‌سازی K را به مقدار V تغییر دهد؛

[1,i] برای ثبت رأی موافق به پیشنهاد i؛

[2,i] برای نهایی‌کردن پیشنهاد i، مشروط بر اینکه آرای کافی ثبت شده باشد.

قرارداد برای هر یک از این موارد بندهایی جداگانه خواهد داشت. همچنین سابقه همه تغییرات بازِ فضای ذخیره‌سازی را همراه با فهرست افرادی که به آن تغییرات رأی داده‌اند نگه می‌دارد و فهرستی از تمام اعضا نیز در آن ثبت می‌شود. هرگاه شمار آرای موافق با یک تغییر در فضای ذخیره‌سازی به دوسوم اعضا برسد، یک تراکنش نهایی‌ساز می‌تواند آن تغییر را اجرا کند.

در این روش، هر فرد می‌تواند شخص دیگری را مأمور کند تا از طرف او رأی بدهد و این واگذاری خاصیت تعدی دارد: اگر A حق رأی خود را به B واگذار کند و B نیز آن را به C بسپارد، در نهایت C تعیین می‌کند که رأی A چه باشد.

چارچوبی پیشرفته‌تر می‌تواند قابلیت‌های رأی‌گیری داخلی برای اقداماتی مانند ارسال تراکنش، افزودن عضو و حذف عضو نیز داشته باشد. حتی ممکن است امکان واگذاری رأی به شیوه «دموکراسی سیال» را فراهم کند. در این روش، هر فرد می‌تواند شخص دیگری را مأمور کند تا از طرف او رأی بدهد و این واگذاری خاصیت تعدی دارد: اگر A حق رأی خود را به B واگذار کند و B نیز آن را به C بسپارد، در نهایت C تعیین می‌کند که رأی A چه باشد.

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

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

کاربردهای بیشتر

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

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

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

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

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

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

۳. جریان داده غیرمتمرکز: در قراردادهای مالی مابه‌التفاوت، ممکن است بتوان جریان داده را با استفاده از پروتکلی به نام «شلینگ‌کوین» یا SchellingCoin غیرمتمرکز کرد. سازوکار پایه شلینگ‌کوین از این قرار است: تعداد N طرف، مقدار یک داده مشخص، مثلاً نرخ ETH/USD، را وارد سامانه می‌کنند. سپس مقادیر مرتب می‌شوند و هر کسی که پاسخ او میان صدک ۲۵ و صدک ۷۵ قرار بگیرد، یک توکن پاداش می‌گیرد. هر شرکت‌کننده انگیزه دارد پاسخی را ارائه کند که انتظار دارد دیگران نیز همان را ارائه دهند. تنها مقداری که شمار زیادی از بازیگران می‌توانند در عمل بر سر آن توافق کنند، پاسخ بدیهی و پیش‌فرض، یعنی حقیقت، است. به این ترتیب، پروتکلی غیرمتمرکز پدید می‌آید که از نظر نظری می‌تواند هر تعداد مقدار را فراهم کند؛ از نرخ ETH/USD و دمای هوای برلین گرفته تا حتی نتیجه یک محاسبه دشوار مشخص.

۴. سپرده‌گذاری امانی چندامضایی هوشمند: بیت‌کوین قراردادهایی برای تراکنش‌های چندامضایی فراهم می‌کند که در آن‌ها، برای مثال، سه کلید از میان پنج کلید مشخص می‌توانند وجوه را خرج کنند. اتریوم امکان تعریف قواعد دقیق‌تری را می‌دهد. برای نمونه، چهار نفر از پنج نفر می‌توانند همه وجوه را خرج کنند؛ سه نفر از پنج نفر اجازه دارند روزانه حداکثر ۱۰ درصد را خرج کنند؛ و دو نفر از پنج نفر می‌توانند روزانه تا ۰٫۵ درصد از وجوه را مصرف کنند. افزون بر این، سازوکار چندامضایی اتریوم ناهم‌زمان است: دو طرف می‌توانند امضاهای خود را در زمان‌های متفاوت روی زنجیره بلوکی ثبت کنند و با ثبت آخرین امضای لازم، تراکنش به‌طور خودکار ارسال می‌شود.

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

با ترکیب بررسی‌های نمونه‌ای با سپرده‌های تضمینی نیز می‌توان از قابل‌اعتماد بودن سامانه اطمینان یافت؛ به این معنا که گره‌ها نتوانند با تقلب سود کنند.

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

البته چنین سامانه‌ای احتمالاً برای همه کارها مناسب نیست. برای مثال، انجام وظایفی که به ارتباط گسترده میان فرایندها نیاز دارند، روی یک ابر بزرگ متشکل از گره‌های متعدد آسان نیست. بااین‌حال، برخی وظایف دیگر را بسیار راحت‌تر می‌توان موازی‌سازی کرد. پروژه‌هایی مانند SETI@home،‏ folding@home و الگوریتم‌های ژنتیک را می‌توان به‌آسانی بر بستر چنین پلتفرمی پیاده‌سازی کرد.

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

۷. بازارهای پیش‌بینی: اگر یک اوراکل یا شلینگ‌کوین در دسترس باشد، پیاده‌سازی بازارهای پیش‌بینی نیز آسان خواهد بود. ترکیب بازارهای پیش‌بینی با شلینگ‌کوین ممکن است نخستین کاربرد فراگیر «فوتارکی» باشد؛ الگویی که می‌تواند به‌عنوان پروتکل حکمرانی سازمان‌های غیرمتمرکز به کار رود.

۸. بازارهای غیرمتمرکز درون‌زنجیره‌ای: چنین بازارهایی می‌توانند سامانه هویت و اعتبار را مبنای فعالیت خود قرار دهند.

نکات و دغدغه‌های گوناگون

پیاده‌سازی اصلاح‌شده پروتکل GHOST

پروتکل «حریصانه‌ترین زیردرختِ مشاهده‌شده با بیشترین وزن» که با سرواژه GHOST شناخته می‌شود، نوآوری‌ای است که نخستین بار یوناتان سومپولینسکی و آویو زوهر در دسامبر ۲۰۱۳ معرفی کردند. انگیزه طراحی GHOST این بود که زنجیره‌های بلوکی با زمان تأیید کوتاه، به دلیل نرخ بالای بلوک‌های کهنه، با کاهش امنیت روبه‌رو می‌شوند.

انتشار هر بلوک در سراسر شبکه مدت‌زمان مشخصی طول می‌کشد. بنابراین، اگر استخراج‌گر A بلوکی را استخراج کند و پیش از آنکه بلوک A به استخراج‌گر B برسد، استخراج‌گر B نیز اتفاقاً بلوک دیگری بسازد، بلوک B در نهایت بلااستفاده خواهد شد و نقشی در امنیت شبکه ایفا نخواهد کرد.

این وضعیت افزون بر پیامدهای امنیتی، مسئله تمرکزگرایی را نیز ایجاد می‌کند. فرض کنید استخراج‌گر A یک استخر استخراج با ۳۰ درصد از توان هش شبکه باشد و استخراج‌گر B نیز ۱۰ درصد از توان هش را در اختیار داشته باشد. در این حالت، A در ۷۰ درصد مواقع در معرض خطر تولید یک بلوک کهنه قرار می‌گیرد؛ زیرا در ۳۰ درصد باقی‌مانده، خود A بلوک قبلی را ساخته است و در نتیجه داده‌های لازم برای ادامه استخراج را بی‌درنگ دریافت می‌کند. در مقابل، احتمال تولید بلوک کهنه برای B به ۹۰ درصد می‌رسد. بنابراین، اگر فاصله زمانی میان بلوک‌ها آن‌قدر کوتاه باشد که نرخ بلوک‌های کهنه بالا برود، موقعیت A صرفاً به دلیل اندازه بزرگ‌تر آن به‌مراتب بهتر خواهد بود.

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

الگوی GHOST و نقش بلوک‌های کهنه

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

برای حل مشکل دوم، یعنی سوگیری به‌سوی تمرکزگرایی، اتریوم از پروتکلی که سومپولینسکی و زوهار شرح داده‌اند فراتر می‌رود و به بلوک‌های کهنه نیز پاداش بلوک می‌دهد. یک بلوک کهنه ۸۷٫۵ درصد از پاداش پایه خود را دریافت می‌کند و «برادرزاده‌ای» که آن بلوک کهنه را در خود می‌گنجاند، ۱۲٫۵ درصد باقی‌مانده را می‌گیرد. بااین‌حال، کارمزد تراکنش‌ها به عموها تعلق نمی‌گیرد.

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

هر بلوک باید یک بلوک والد را مشخص کند و می‌تواند صفر یا چند عمو نیز معرفی کند.

اگر بلوک موردنظر را B بنامیم، هر عمو باید فرزند مستقیم نیای نسل kام بلوک B باشد؛ به‌طوری‌که ۲ ≤ k ≤ ۷ باشد.

عمو نمی‌تواند یکی از نیاکان بلوک B باشد.

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

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

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

به‌ازای هر عموی U که در بلوک B گنجانده می‌شود، استخراج‌کننده B معادل ۳٫۱۲۵ درصد پاداش اضافی بر پاداش کوین‌بیس خود دریافت می‌کند و استخراج‌کننده U نیز ۹۳٫۷۵ درصد پاداش استاندارد کوین‌بیس را می‌گیرد.

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

کارمزدها

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

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

بااین‌همه، این استدلال یک مشکل اساسی دارد: پردازش تراکنش بازار نیست. در نگاه نخست ممکن است جذاب به نظر برسد که پردازش تراکنش را خدمتی بدانیم که استخراج‌کننده به فرستنده ارائه می‌کند، اما در عمل هر تراکنشی که یک استخراج‌کننده در بلوک بگنجاند باید به‌وسیله تک‌تک گره‌های شبکه پردازش شود. بنابراین، بخش اعظم هزینه پردازش تراکنش را اشخاص ثالث می‌پردازند، نه استخراج‌کننده‌ای که درباره گنجاندن یا نگنجاندن تراکنش تصمیم می‌گیرد. ازاین‌رو، احتمال بروز مشکلاتی از نوع «تراژدی منابع مشترک» بسیار زیاد است.

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

یک تراکنش به انجام k عملیات منجر می‌شود و به هر استخراج‌کننده‌ای که آن را در بلوک بگنجاند، پاداشی برابر با kR پیشنهاد می‌کند. مقدار R را فرستنده تعیین می‌کند و استخراج‌کننده می‌تواند k و R را از پیش، دست‌کم به‌طور تقریبی، مشاهده کند.

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

N گره استخراج وجود دارد و همه آن‌ها دقیقاً توان پردازشی برابری دارند؛ بنابراین، سهم هر گره برابر با ۱/N از کل توان پردازشی است.

هیچ گره کاملِ غیر‌استخراج‌کننده‌ای وجود ندارد.

استخراج‌کننده در صورتی حاضر است یک تراکنش را پردازش کند که پاداش مورد انتظار از هزینه بیشتر باشد. پاداش مورد انتظار برابر با kR/N است، زیرا استخراج‌کننده برای پردازش بلوک بعدی شانسی برابر با ۱/N دارد. هزینه پردازش آن تراکنش برای استخراج‌کننده نیز صرفاً kC است. در نتیجه، استخراج‌کنندگان تراکنش‌هایی را می‌پذیرند که در آن‌ها:

kR/N > kC

باشد؛ یا به‌شکل ساده‌تر:

R > NC

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

اما در واقعیت، چند انحراف مهم از این فرض‌ها وجود دارد:

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

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

گره‌های کاملِ غیر‌استخراج‌کننده در عمل وجود دارند.

توزیع توان استخراج ممکن است در عمل به‌شدت نابرابر شود.

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

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

مشکلات اصلی به عامل‌های سوم و چهارم مربوط‌اند. برای حل آن‌ها، کافی است یک سقف شناور برقرار شود: هیچ بلوکی نباید بیش از حاصل‌ضرب BLK_LIMIT_FACTOR در میانگین متحرک نمایی بلندمدت، عملیات داشته باشد. به‌طور مشخص، BLK_LIMIT_FACTOR و EMA_FACTOR دو مقدار ثابت‌اند که فعلاً به‌ترتیب روی ۶۵۵۳۶ و ۱٫۵ تنظیم خواهند شد، اما احتمالاً پس از تحلیل‌های بیشتر تغییر می‌کنند.

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

بلوک‌های بزرگ‌تر، هم به این دلیل که از نظر فیزیکی حجم بیشتری دارند و هم به این علت که پردازش و اعتبارسنجیِ گذارهای وضعیت تراکنش‌هایشان زمان بیشتری می‌برد، دیرتر در شبکه منتشر می‌شوند. این بازدارندگیِ ناشی از تأخیر در بیت‌کوین ملاحظه‌ای مهم است، اما به‌دلیل استفاده اتریوم از پروتکل GHOST، در اتریوم اهمیت کمتری دارد. بنابراین، اتکا به محدودیت‌های تنظیم‌شده برای اندازه بلوک، مبنایی باثبات‌تر فراهم می‌کند.

محاسبات و کامل‌بودن تورینگ

نکته مهم این است که ماشین مجازی اتریوم، یا EVM، از نظر تورینگ کامل است. این ویژگی به آن معناست که کد EVM می‌تواند هر محاسبه‌ای را که اصولاً قابل انجام باشد بیان کند؛ حلقه‌های بی‌نهایت نیز در همین دسته قرار می‌گیرند. کد EVM به دو شیوه امکان ایجاد حلقه را فراهم می‌کند. نخست، دستور JUMP به برنامه اجازه می‌دهد به نقطه‌ای پیشین در کد بازگردد و دستور JUMPI نیز پرش مشروط را ممکن می‌کند. به این ترتیب می‌توان دستورهایی مانند while x < 27: x = x * 2 را پیاده کرد. دوم، قراردادها می‌توانند قراردادهای دیگری را فراخوانی کنند و از این راه، احتمال شکل‌گیری حلقه بر اثر بازگشت یا فراخوانی بازگشتی وجود دارد.

این قابلیت طبعاً مسئله‌ای ایجاد می‌کند: آیا کاربران مخرب می‌توانند با واداشتن ماینرها و گره‌های کامل به ورود در یک حلقه بی‌نهایت، عملاً آن‌ها را از کار بیندازند؟ منشأ این مسئله، موضوعی در علوم کامپیوتر است که «مسئله توقف» نام دارد. به‌طور کلی، هیچ راهی وجود ندارد که مشخص کنیم یک برنامه معین سرانجام متوقف خواهد شد یا نه.

همان‌طور که در بخش گذار وضعیت توضیح داده شد، راه‌حل اتریوم این است که هر تراکنش ملزم باشد حداکثر تعداد گام‌های محاسباتیِ مجاز خود را تعیین کند. اگر اجرای تراکنش به محاسبات بیشتری نیاز داشته باشد، تغییرات ناشی از اجرا بازگردانده می‌شود، اما کارمزد همچنان پرداخت خواهد شد. پیام‌ها نیز به همین شیوه عمل می‌کنند. نمونه‌های زیر انگیزه و منطق این راه‌حل را روشن می‌کنند:

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

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

مهاجمی قراردادی را می‌بیند که کدی تقریباً به این شکل دارد: send(A,contract.storage[A]); contract.storage[A] = 0. سپس تراکنشی می‌فرستد که گس آن فقط برای اجرای گام نخست کافی است، نه گام دوم؛ یعنی برداشت انجام می‌شود، اما اجازه داده نمی‌شود موجودی کاهش یابد. نویسنده قرارداد لازم نیست نگران محافظت در برابر چنین حمله‌ای باشد، زیرا اگر اجرا در میانه راه متوقف شود، تغییرات انجام‌شده بازگردانده خواهند شد.

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

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

افزون بر این، ناکامل‌بودن تورینگ حتی محدودیت چندان بزرگی هم به نظر نمی‌رسد. از میان همه نمونه‌های قراردادی که تا آن زمان در داخل مجموعه طراحی شده بود، فقط یک نمونه به حلقه نیاز داشت. حتی در همان مورد نیز می‌شد با ۲۶ بار تکرار یک قطعه کد یک‌خطی، حلقه را حذف کرد. با توجه به پیامدهای جدی کامل‌بودن تورینگ و فایده محدود آن، این پرسش مطرح می‌شود که چرا نباید صرفاً از زبانی استفاده کرد که از نظر تورینگ ناکامل باشد؟

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

اکنون تراکنشی به قرارداد A بفرستید. به این ترتیب، تنها با ۵۱ تراکنش، قراردادی خواهیم داشت که اجرای آن به ۲^۵۰ گام محاسباتی نیاز دارد. ماینرها می‌توانند بکوشند چنین بمب‌های منطقی‌ای را از پیش شناسایی کنند. برای این کار، باید در کنار هر قرارداد مقداری نگه دارند که حداکثر تعداد گام‌های محاسباتیِ قابل اجرای آن را مشخص کند و این مقدار را برای قراردادهایی که قراردادهای دیگر را به‌صورت بازگشتی فراخوانی می‌کنند نیز محاسبه کنند. بااین‌حال، چنین روشی مستلزم آن است که ماینرها قراردادهایی را که قراردادهای دیگری می‌سازند ممنوع کنند، زیرا ایجاد و اجرای هر ۲۶ قرارداد یادشده را می‌توان به‌آسانی در یک قرارداد واحد گنجاند.

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

ارز و نحوه انتشار

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

برای سهولت استفاده و نیز جلوگیری از اختلاف‌نظرهای احتمالی در آینده ــ مشابه بحث جاری در بیت‌کوین بر سر mBTC،‏ uBTC و ساتوشی ــ نام واحدها از پیش تعیین می‌شود:

۱: wei یا «وی»

۱۰^۱۲: szabo یا «سابو»

۱۰^۱۵: finney یا «فینی»

۱۰^۱۸: ether یا «اتر»

این ساختار را باید نسخه‌ای بسط‌یافته از مفهومِ… دانست.

نام‌گذاری واحدهای پولی می‌تواند مانند «دلار» و «سِنت» یا «BTC» و «ساتوشی» باشد. انتظار می‌رود در آینده نزدیک، «اتر» (ether) برای تراکنش‌های عادی، «فینی» (finney) برای ریزتراکنش‌ها، و «سابو» (szabo) و «وی» (wei) در بحث‌های فنی مربوط به کارمزدها و پیاده‌سازی پروتکل به کار روند. دیگر واحدهای پولی شاید بعدها مفید واقع شوند، اما در حال حاضر نباید در نرم‌افزارهای کارخواه گنجانده شوند.

الگوی انتشار اتر

الگوی انتشار به این صورت خواهد بود:

اتر طی یک عرضه عمومی ارز و با نرخ ۱۰۰۰ تا ۲۰۰۰ اتر به‌ازای هر BTC عرضه خواهد شد. هدف این سازوکار، تأمین مالی سازمان اتریوم و پرداخت هزینه‌های توسعه است؛ روشی که پلتفرم‌های دیگری مانند Mastercoin و NXT نیز با موفقیت از آن استفاده کرده‌اند. خریداران زودتر از تخفیف‌های بیشتری برخوردار خواهند شد. تمام BTCهای حاصل از عرضه برای پرداخت حقوق و پاداش‌های توسعه‌دهندگان به کار خواهد رفت و همچنین در پروژه‌های انتفاعی و غیرانتفاعی گوناگون در زیست‌بوم اتریوم و رمزارزها سرمایه‌گذاری خواهد شد.

مقداری برابر با ۰٫۰۹۹x از کل مقدار فروخته‌شده، یعنی از مجموع ۶۰٬۱۰۲٬۲۱۶ اتر، به سازمان اختصاص می‌یابد تا هم مشارکت‌کنندگان اولیه جبران خدمت شوند و هم هزینه‌هایی که پیش از ایجاد بلوک پیدایش برحسب ETH محاسبه می‌شوند، پرداخت شوند.

مقدار دیگری برابر با ۰٫۰۹۹x از کل میزان فروخته‌شده، به‌عنوان ذخیره بلندمدت نگهداری خواهد شد.

از آن زمان به بعد نیز هر سال و برای همیشه، مقداری برابر با ۰٫۲۶x از کل میزان فروخته‌شده به استخراج‌کنندگان اختصاص خواهد یافت.

نرخ رشد بلندمدت عرضه، برحسب درصد

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

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

دلیل در نظر گرفتن صندوق ذخیره را می‌توان چنین توضیح داد: اگر صندوق ذخیره‌ای وجود نداشت و برای حفظ همان نرخ تورم، انتشار خطی به ۰٫۲۱۷x کاهش می‌یافت، مقدار کل اتر ۱۶٫۵ درصد کمتر می‌شد و در نتیجه، ارزش هر واحد ۱۹٫۸ درصد افزایش پیدا می‌کرد. بنابراین در حالت تعادل، ۱۹٫۸ درصد اتر بیشتر در عرضه عمومی خریداری می‌شد و ارزش هر واحد دوباره دقیقاً به همان سطح قبلی بازمی‌گشت. در این حالت، سازمان نیز ۱٫۱۹۸x برابر BTC بیشتر در اختیار می‌داشت. می‌توان این مقدار را به دو بخش تقسیم کرد: BTC اولیه و ۰٫۱۹۸x اضافه. پس این وضعیت دقیقاً با وجود صندوق ذخیره معادل است، اما یک تفاوت مهم دارد: سازمان در چنین حالتی دارایی خود را صرفاً به شکل BTC نگه می‌دارد و در نتیجه انگیزه‌ای برای پشتیبانی از ارزش واحد اتر نخواهد داشت.

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

این فرض نظری نیز مطرح است که همواره بخشی از سکه‌ها بر اثر بی‌احتیاطی، مرگ و عوامل مشابه از دست می‌روند و می‌توان میزان سکه‌های ازدست‌رفته را به‌صورت درصدی از کل عرضه در هر سال مدل‌سازی کرد. بر این اساس، کل عرضه ارزِ در گردش سرانجام در مقداری تثبیت خواهد شد که برابر است با میزان انتشار سالانه تقسیم بر نرخ از‌دست‌رفتن سکه‌ها. برای مثال، اگر نرخ از‌دست‌رفتن سالانه ۱ درصد باشد، وقتی عرضه به ۲۶X برسد، هر سال ۰٫۲۶X استخراج و ۰٫۲۶X نیز از دست خواهد رفت و به این ترتیب تعادل شکل می‌گیرد.

باید توجه داشت که احتمال دارد اتریوم در آینده برای تأمین امنیت به الگوی «اثبات سهام» یا PoS روی بیاورد. چنین تغییری نیاز به انتشار سالانه را به مقداری میان صفر و ۰٫۰۵X کاهش خواهد داد. اگر سازمان اتریوم منابع مالی خود را از دست بدهد یا به هر دلیل دیگری از میان برود، یک «قرارداد اجتماعی» باز گذاشته می‌شود: هر کسی حق دارد نسخه‌ای نامزد برای آینده اتریوم ایجاد کند، با این شرط یگانه که مقدار اتر حداکثر برابر فرمول زیر باشد:

۶۰٬۱۰۲٬۲۱۶ × (۱٫۱۹۸ + ۰٫۲۶ × n)

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

تمرکزگرایی در استخراج

الگوریتم استخراج بیت‌کوین به این صورت عمل می‌کند که استخراج‌کنندگان، تابع SHA-256 را میلیون‌ها بار و پی‌درپی روی نسخه‌هایی با تغییرات جزئی از سرآیند بلوک محاسبه می‌کنند تا سرانجام یکی از گره‌ها به نسخه‌ای برسد که هش آن کمتر از مقدار هدف باشد؛ مقدار هدف هنگام نگارش حدود ۲^۱۹۲ است. با این حال، این الگوریتم استخراج در برابر دو نوع تمرکزگرایی آسیب‌پذیر است.

نخست آنکه زیست‌بوم استخراج تحت سلطه ASICها، یعنی «مدارهای مجتمع با کاربرد خاص»، درآمده است. ASICها تراشه‌های رایانه‌ای هستند که مشخصاً برای استخراج بیت‌کوین طراحی شده‌اند و از همین رو، در انجام این کار خاص هزاران برابر کارآمدترند. در نتیجه، استخراج بیت‌کوین دیگر فعالیتی به‌شدت غیرمتمرکز و برابرگرایانه نیست و مشارکت مؤثر در آن به میلیون‌ها دلار سرمایه نیاز دارد.

دوم آنکه بیشتر استخراج‌کنندگان بیت‌کوین در عمل اعتبارسنجی بلوک را به‌صورت محلی انجام نمی‌دهند؛ در عوض، به یک استخر استخراج متمرکز متکی‌اند تا سرآیندهای بلوک را در اختیارشان بگذارد. می‌توان گفت این مشکل حتی جدی‌تر است: هنگام نگارش، سه استخر استخراج بزرگ در مجموع و به‌طور غیرمستقیم حدود ۵۰ درصد توان پردازشی شبکه بیت‌کوین را در کنترل دارند. البته شدت این مشکل تا حدی کاهش می‌یابد، زیرا اگر یک استخر یا ائتلافی از استخرها برای اجرای حمله ۵۱ درصدی تلاش کند، استخراج‌کنندگان می‌توانند به استخرهای دیگر منتقل شوند.

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

دوم اینکه استخراج مستلزم دسترسی به کل زنجیره‌بلوک است؛ بنابراین استخراج‌کنندگان ناچارند تمام زنجیره‌بلوک را ذخیره کنند و دست‌کم توانایی راستی‌آزمایی تک‌تک تراکنش‌ها را داشته باشند.

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

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

مقیاس‌پذیری

یکی از نگرانی‌های رایج درباره اتریوم، مسئله مقیاس‌پذیری است. اتریوم نیز مانند بیت‌کوین از این کاستی رنج می‌برد که هر تراکنش باید به‌وسیله تمام گره‌های شبکه پردازش شود. اندازه کنونی زنجیره‌بلوک بیت‌کوین حدود ۱۵ گیگابایت است و در هر ساعت تقریباً ۱ مگابایت به آن افزوده می‌شود. اگر شبکه بیت‌کوین قرار بود ۲۰۰۰ تراکنش در ثانیه، یعنی حجم پردازش شبکه ویزا، را انجام دهد، اندازه زنجیره‌بلوک آن هر سه ثانیه ۱ مگابایت افزایش می‌یافت؛ به بیان عددی، این رشد برابر با ۱ گیگابایت در ساعت و ۸ ترابایت در سال بود.

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

اندازه بسیار بزرگ زنجیره‌بلوک خطر تمرکزگرایی را به همراه دارد. اگر اندازه زنجیره‌بلوک، برای نمونه، به ۱۰۰ ترابایت برسد، محتمل‌ترین سناریو این است که فقط شمار بسیار اندکی از کسب‌وکارهای بزرگ گره کامل اجرا کنند و همه کاربران عادی به گره‌های سبک SPV، یعنی گره‌های مبتنی بر «راستی‌آزمایی ساده‌شده پرداخت»، روی بیاورند. در چنین وضعیتی ممکن است گره‌های کامل با یکدیگر متحد شوند و همگی توافق کنند که به روشی سودآور تقلب کنند؛ برای مثال، پاداش هر بلوک را تغییر دهند و به خودشان BTC بدهند. گره‌های سبک هیچ راهی برای تشخیص فوری چنین تقلبی نخواهند داشت.

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

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

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

اگر استخراج‌کننده‌ای بلوکی نامعتبر منتشر کند، یا قالب بلوک ایراد دارد یا وضعیت S[n] نادرست است. از آنجا که می‌دانیم S[0] درست است، ناگزیر باید نخستین وضعیت نادرستی مانند S[i] وجود داشته باشد که وضعیت پیش از آن، یعنی S[i-1]، صحیح است. گره راستی‌آزما شاخص i را همراه با یک «اثبات نامعتبربودن» ارائه می‌کند. این اثبات از زیرمجموعه‌ای از گره‌های درخت پاتریشیا تشکیل می‌شود که برای پردازش رابطه زیر لازم‌اند:

APPLY(S[i-1],TX[i]) → S[i]

سپس گره‌ها می‌توانند با استفاده از همان گره‌های درخت پاتریشیا، آن بخش از محاسبه را اجرا کنند و ببینند که S[i] حاصل از محاسبه با S[i] ارائه‌شده مطابقت ندارد.

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

جمع‌بندی

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

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

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

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