برگه سفید اتریوم

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

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

محققان و دانشگاهیان که به دنبال یک نسخه تاریخی یا متعارف از وایت پیپر [از دسامبر 2014] هستند، باید از این PDF استفاده کنند.

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

توسعه بیت کوین توسط ساتوشی ناکاموتو در سال ۲۰۰۹ اغلب به عنوان یک تحول اساسی درصنعت پول و رمزارز مورد استقبال قرار گرفته است، اولین نمونه یک دارایی دیجیتال که به طور همزمان نه هیچ پشتوانه یا "ارزش ذاتی(opens in a new tab)" دارد و نه هیچ مرجع عرضه متمرکز یا کنترل کننده. با این حال، یکی از بخش‌های - شاید مهم تر - تجربه بیت کوین زیربنای فناوری زنجیره بلوکی آن به عنوان ابزاری برای اجماع توزیع شده است، و توجهات به سرعت در حال شروع به تغییر به این جنبه دیگر بیت کوین است. کاربردهای جایگزین رایج فناوری بلاک چین شامل استفاده از دارایی های دیجیتال درون بلاک چین برای نشان دادن ارزهای سفارشی و ابزارهای مالی "سکه های رنگی(opens in a new tab) ویرایش"، مالکیت یک دستگاه فیزیکی زیربنایی ("اموال هوشمند(opens in a new tab)")، دارایی‌های غیرقابل تعویض مانند نام‌های دامنه ("Namecoin(opens in a new tab)")، و همچنین برنامه‌های پیچیده‌تر شامل داشتن دارایی‌های دیجیتال که مستقیماً توسط یک قطعه کد کنترل می‌شوند. اجرای قوانین دلخواه ("هوشمند قراردادها(opens in a new tab)") یا حتی "

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

مقدمه ای بر بیت کوین و مفاهیم موجود

تاریخچه

مفهوم ارز دیجیتال نامتمرکز و همچنین برنامه های جایگزین مانند ثبت اموال، برای دهه ها وجود داشته است. پروتکل‌های پول نقد الکترونیکی ناشناس در دهه‌های 1980 و 1990، عمدتاً متکی به یک رمزنگاری بدوی به نام کورکننده چاومین، ارزی با درجه بالایی از حریم خصوصی ارائه می‌ شدند، اما پروتکل‌ها عمدتاً به دلیل اتکا به یک واسطه متمرکز نتوانستند مورد توجه قرار گیرند. در سال 1998، b-money(opens in a new tab) از Wei Dai نخستین طرحی شد که ایده ساخت پول از طریق حل معما های محاسباتی و نیز اجماع نامتمرکز را معرفی می‌کرد، اما جزئیات طرح پیرامون اینکه اجماع نامتمرکز در واقع چگونه می‌توانست تعبیه شود ناچیز بود. در سال 2005، هال فینی مفهوم اثبات کار قابل استفاده مجدد(opens in a new tab) را معرفی کرد، سیستمی که از ایده‌هایی از b-money به همراه پازل‌های سخت محاسباتی Hashcash آدام بک برای ایجاد مفهومی برای یک ارز دیجیتال بهره می‌برد، اما بار دیگر به دلیل تکیه بر محاسبات قابل اعتماد به عنوان یک بک‌اند، دور از ایده‌آل قرار گرفت. در سال 2009، یک ارز غیرمتمرکز برای اولین بار در عمل توسط ساتوشی ناکاموتو پیاده‌سازی شد، که ترکیبی از اصول اولیه برای مدیریت مالکیت از طریق رمزنگاری کلید عمومی همچنین الگوریتم اجماع برای پیگیری صاحبان سکه‌ها، معروف به "اثبات کار" اجرا شد.

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

بیت کوین به عنوان یک سیستم انتقال حالت

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

APPLY(S,TX) -> S' or ERROR

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

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

اما:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

"وضعیت" در بیت کوین مجموعه ای از تمام کوین ها (از لحاظ فنی، "خروجی های تراکنش خرج نشده" یا UTXO) است که ضرب شده اند و هنوز خرج نشده اند، با هر UTXO دارای یک اسم و یک مالک (که با یک آدرس 20 بایتی تعریف می شود. اساسا یک کلید عمومی رمزنگاری است^fn1). یک تراکنش شامل یک یا چند ورودی است که هر ورودی حاوی ارجاع به یک UTXO موجود و یک امضای رمزنگاری شده توسط کلید خصوصی مرتبط با آدرس مالک است و یک یا چند خروجی که هر خروجی حاوی یک UTXO جدید است که باید به آن حالت اضافه شود.

تابع انتقال حالت APPLY(S,TX) -> S' را می توان تقریباً به صورت زیر تعریف کرد:

1. برای هر ورودی در TX:
   • اگر UTXOی ارجاعی در S نیست، خطا را برگردان.
   • اگر امضای ارائه شده با صاحب UTXO مطابقت ندارد، خطا را برگردان.
2. اگر مجموع نام‌های تمام UTXO ورودی کمتر از مجموع نام‌های همه UTXO خروجی باشد، خطا را برگردان.
3. S را با حذف تمام ورودی UTXO و اضافه شدن تمام خروجی UTXO برگردان.

نیمه‌ی اول از گام اول مانع از این می‌شود که فرستنده‌ها کوین‌هایی که وجود ندارند را خرج کنند، نیمه‌ی دوم از گام اول مانع از این می‌شود که فرستنده‌ها کوین‌های دیگر افراد را خرج نکنند، و گام دوم فرستنده‌ را مجبور می‌کند که ارزش را حفظ کند. برای این که از این برای پرداخت استفاده کنیم، پروتکل به شکل زیر است. فرض کنید که آلیس می‌خواهد ۱۱٬۷ BTC را به باب بفرستد. ابتدا آلیس به دنبال یک مجموعه از UTXO از آن‌هایی که خود مالک آن‌هاست می‌گردد که مجموعشان حداقل ۱۱٬۷ BTC شود. واقع‌بینانه، آلیس نخواهد توانست که دقیقا ۱۱٬۷ BTC را بیابد؛ فرض کنید کمترین میزانی که آلیس می‌تواند بسازد ۶+۴+۲=۱۲ باشد. در گام بعدی او یک تراکنش با سه ورودی گفته‌شده و دو خروجی می‌سازد. اولین خروجی ۱۱٬۷ BTC به آدرس باب خواهد بود و دومین خروجی مقدار ۰٬۳ BTC باقیمانده به عنوان «پول خرد»، به آدرس خود آلیس است.

استخراج

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

الگوریتمی که نشان می‌دهد یک بلوک معتبر است به صورت زیر توضیح داده می‌شود:

1. بررسی کنید که آیا بلوک قبلی که توسط بلوک به آن ارجاع داده شده وجود دارد و معتبر است یا خیر.
2. بررسی کنید که مُهر زمانی بلوک بزرگتر از بلوک قبلی باشد^fn2 و کمتر از 2 ساعت در آینده باشد
3. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
4. حالت S[0] را حالت پایانی بلوک قبل بگذار.
5. فرض کن TX لیست تراکنش‌های بلوک با تعداد n تراکنش است. برای همه i در 0...n-1، S[i+1] = APPLY(S[i], TX[i]) را تنظیم کنید /code> اگر هر برنامه ای خطا را برمی‌گرداند، از آن خارج شوید و false را برگردانید. True را برگردانید و S[n] را به عنوان وضعیت در انتهای این بلوک ثبت کنید.

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

شرط صحتی که در دیگر سیستم‌ها دیده نمی‌شود و در لیست بالا به آن اشاره شد، لازمه‌ی «اثبات کار» است. شرط دقیق به این شکل است که هش double-SHA256 هر بلوک، به عنوان یک عدد ۲۵۶ بیتی، باید کمتر از یک هدف به شکل پویا متغیر باشد، که در زمان نوشتن این مقاله ۲^۱۸۷ است. هدف از این امر "سخت کردن" ساخت بلوک از لحاظ محاسباتی و در نتیجه باز داشتن مهاجمان sybil از بازسازی کل زنجیره بلوکی به نفع خودشان است. چون SHA256 طراحی شده تا یک تابع کاملا شبه تصادفی غیرقابل پیشبینی باشد، تنها راه ساخت یک بلوک معتبر صرفا آزمون و خطا، اضافه کردن نانس و دیدن این است که آیا هش جدید تطابق می‌کند یا خیر.

در هدف کنونی ~۲^۱۸۷، شبکه باید به طور میانگین اقدام به ~۲^۶۹ آزمون پیش از یافتن یک بلوک معتبر بکند; به طور کلی، هدف به ازای هر ۲۰۱۶ بلوک توسط شبکه بازتنظیم می‌شود به شکلی که به طور میانگین هر ۱۰ دقیقه یک بلوک جدید توسط یک گره در شبکه تولید شود. به منظور جبران کار ماینرها برای این محاسبات ، استخراجگر هر بلوک حق دارد یک تراکنش را شامل شود که به خودشان 12.5 بیت کوین می دهد. به‌علاوه، اگر هر تراکنشی در ورودی‌های خود ارزش کل بالاتری نسبت به خروجی‌های خود داشته باشد، تفاوت نیز به عنوان «کارمزد تراکنش» به ماینر می‌رسد. اتفاقاً این تنها مکانیزمی است که توسط آن BTC صادر می شود. در اول ایجاد این شبکه هیچ سکه ای وجود نداشت.

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

1. تعداد 100 بیتکوین را به یک صرافی در ازای مقداری محصول بفرستید (ترجیحاً کالای دیجیتالی با تحویل سریع)
2. منتظر تحویل محصول میماند
3. یک تراکنش دیگر ایجاد کرده و همان 100 بیت کوین را برای خودش ارسال میکند
4. سعی کنید شبکه را متقاعد کنید که تراکنش او با خودش اولین معامله بوده است.

هنگامی که مرحله (1) انجام شد، پس از چند دقیقه برخی از ماینرها تراکنش را در یک بلوک، مثلاً بلوک شماره 270000، وارد می کنند. بعد از حدود یک ساعت، پنج بلوک دیگر به زنجیره پس از آن بلوک، اضافه میشود که هر کدام از این بلوک ها به طور غیر مستقیم به تراکنش اشاره کرده و بنابراین آن را تایید میکنند. در این نقطه، تاجر پرداخت را نهایی تلقی میکند و محصول را تحویل میدهد. همچنان که فرض کردیم این کالا دیجیتال است و تحویل آن فوری است. حال مهاجم تراکنش دیگری را ایجاد میکند و 100 بیت کوین را به خودش ارسال میکند. اگر مهاجم به سادگی آن را رها کند، تراکنش پردازش نخواهد شد. استخراج کنندگان تلاش میکنند که APPLY(S, TX) را اعمال کنند و متوجه میشوند که TX یک UTXO را مصرف میکند که دیگر در آن حالت نیست. بنابراین در عوض آن، مهاجم یک انشعاب (فورک) از زنجیره بلوکی را ایجاد میکند که با استخراج نسخه دیگری از بلوک 270 شروع میشود که به همان بلوک 269، به عنوان بلوک مادر اشاره میکند، اما با معرفی تراکنش جدید در جای تراکنش قدیمی. از آنجا که داده های بلوک متفاوت است، این مستلزم انجام مجدد اثبات کار است. علاوه بر این، نسخه جدید بلوک 270 مهاجم دارای هش متفاوتی است، بنابراین بلوک های اصلی 271 تا 275 به آن اشاره نمی کنند. بنابراین، زنجیره اصلی و زنجیره جدید مهاجم کاملاً جدا هستند. قانون این است که در یک فورک طولانی‌ترین زنجیره بلوکی حقیقی در نظر گرفته می‌شود، و بنابراین ماینرهای قانونی روی زنجیره ۲۷۵ کار می‌کنند در حالی که مهاجم به تنهایی روی زنجیره ۲۷۰ کار می‌کند. برای اینکه مهاجم بتواند زنجیره بلوکی خود را تبدیل به طولانی‌ترین رنجیره کند، باید قدرت محاسباتی بیشتری نسبت به مجموع سایر شبکه‌ها داشته باشد تا بتواند به آن‌ها برسد (یعنی، "حمله 51٪").

درختان Merkle

طرف چپ: کافی است که فقط تعداد کمی از گره ها را در یک درخت Merkle ارائه داد تا اثبات اعتبار شاخه ایجاد شود.

طرف راست: هر تلاشی برای تغییر هر بخشی از درخت Merkle سرانجام منجر به عدم سازگاری در جایی در بالای زنجیره میشود.

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

پروتکل درخت Merkle به طور قابل دفاعی در ماندگاری دراز مدت نقش اساسی دارد. یک گره کامل در شبکه بیت کوین، گره ای است که کلیت یک بلوک را ذخیره و پردازش میکند و حدود 15 گیگابایت از فضای دیسک شبکه بیت کوین را در آپریل 2014 اشغال میکرد و هر ماه حدود یک گیگابایت به این مقدار اضافه میشد. در حال حاضر، این برای برخی از رایانه‌های دسکتاپ و نه تلفن‌ها قابل اجرا است و بعداً در آینده فقط مشاغل و علاقه‌مندان می‌توانند در آن شرکت کنند. پروتکلی به نام "تأیید پرداخت ساده" (SPV) اجازه می دهد تا کلاس دیگری از گره ها به نام "گره های سبک" وجود داشته باشد که هدرهای بلوک را دانلود می کنند، اثبات کار روی هدرهای بلوک را تأیید می کنند و سپس فقط "شاخه ها"ی مرتبط با تراکنش هایی که به آنها مربوط است را دانلود می کنند. این به گره‌های سبک اجازه می‌دهد تا با ضمانت امنیتی قوی، وضعیت هر تراکنش بیت‌کوین و موجودی فعلی آن‌ها را تعیین کنند، در حالی که تنها بخش بسیار کوچکی از کل زنجیره بلوکی را دانلود می‌کنند.

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

ایده گرفتن ایده اصلی زنجیره بلوکی و اعمال آن در مفاهیم دیگر نیز سابقه طولانی دارد. در سال 2005، نیک زابو به مفهوم عناوین ملکی ایمن با اختیار مالک(opens in a new tab)، سندی که چگونگی "پیشرفت های جدید در فناوری پایگاه داده تکراری" را توضیح می دهد اشاره کرد. یک سیستم مبتنی بر بلاکچین برای ذخیره یک رجیستری از اینکه چه کسی امکانپذیر است که مالک چه زمینی است و یک چارچوب مفصل از جمله مفاهیمی از این قبیل ایجاد می کند به عنوان خانه داری، مالکیت نامناسب و مالیات زمین میلادی ایجاد می کند. با این حال، متأسفانه هیچ سیستم پایگاه داده تکثیر شده مؤثری در آن زمان موجود نبود، و بنابراین این پروتکل هرگز در عمل اجرا نشد. با این حال، پس از سال 2009، هنگامی که اجماع غیرمتمرکز بیت کوین توسعه یافت، تعدادی از برنامه های کاربردی جایگزین به سرعت شروع به ظهور کردند.

• Namecoin - ایجاد شده در سال 2010، Namecoin(opens in a new tab) به بهترین وجه به عنوان یک پایگاه داده ثبت نام غیرمتمرکز توصیف می شود. در پروتکل های غیرمتمرکز مانند Tor، Bitcoin و BitMessage، باید راهی برای شناسایی حساب ها وجود داشته باشد تا افراد دیگر بتوانند با آنها تعامل داشته باشند، اما در همه راه حل های موجود، تنها نوع شناسه موجود یک هش شبه تصادفی مانند 1LW79wp5ZBqaHW1jL5TCiBCrhWQYHagUt است. در حالت ایده آل، شخصی ممکن است دوست داشته باشد که بتواند یک حساب کاربری با نامی مانند "جورج" داشته باشد. با این حال، مشکل این است که اگر یک نفر بتواند یک حساب کاربری به نام "جورج" ایجاد کند، شخص دیگری نیز می تواند از همین فرآیند برای ثبت "جورج" برای خود و جعل هویت آنها استفاده کند. تنها راه حل یک پارادایم اول به فایل است که در آن ثبت کننده اول موفق می شود و دومی شکست می خورد - مشکلی که کاملاً برای پروتکل اجماع بیتکوین متناسب است. Namecoin قدیمی ترین و موفق ترین مدل پیاده سازی شده سیستم ثبت نام با استفاده از چنین ایده ای است.
• سکه های رنگی - هدف سکه های رنگی(opens in a new tab) این است که به عنوان پروتکلی عمل کند تا به مردم اجازه دهد رمزارزهای خود را ایجاد کنند - یا در مورد مهم پیش پا افتاده ارز با یک واحد، توکن های دیجیتال، در بلاکچین بیت کوین. در پروتکل کوین‌های رنگی، یک ارز جدید با اختصاص دادن یک رنگ به یک بیت کوین UTXO خاص به صورت عمومی یک ارز جدید صادر می‌کند و پروتکل به صورت بازگشتی رنگ سایر UTXO‌ها را با رنگ ورودی‌هایی که تراکنش ایجاد می‌کند، مشخص می‌کند. (برخی قوانین خاص در مورد ورودی‌های رنگی مخلوط اعمال می‌شود). این مورد به کاربران اجازه می‌دهد تا کیف پول‌هایی را که فقط حاوی UTXO با یک رنگ خاص هستند نگهداری کنند و آن‌ها را مانند بیت‌کوین‌های معمولی به اطراف بفرستند و از طریق بلاک‌چین به عقب برگردند تا رنگ هر UTXO دریافتی را تعیین کنند.
• Metacoins - ایده پشت متاکوین داشتن پروتکلی است که بر روی بستر بیتکوین زندگی می کند، از تراکنش های بیتکوین برای ذخیره تراکنش های متاکوین استفاده می کند، اما دارای یک تابع انتقال حالت متفاوت یعنی APPLY' است،. از آنجایی که پروتکل متاکوین نمی تواند از نمایش تراکنش های متاکوین نامعتبر در بلاکچین بیتکوین جلوگیری کند، قانونی اضافه می شود که اگر APPLY'(S,TX) خطایی را برگرداند، پروتکل به طور پیش فرض به APPLY'( S,TX) = S بر می گردد. این مورد یک مکانیسم آسان برای ایجاد یک پروتکل ارز دیجیتال دلخواه، با ویژگی‌های پیشرفته است که نمی‌تواند در داخل بیت‌کوین با هزینه توسعه بسیار پایین پیاده‌سازی شود، زیرا پیچیدگی‌های استخراج و شبکه‌سازی قبلاً توسط پروتکل بیت‌کوین مدیریت می‌شود. متاکوین‌ها برای اجرای برخی از کلاس‌های قراردادهای مالی، ثبت نام و مبادلات غیرمتمرکز استفاده شده‌اند.

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

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

اسکریپت نویسی

درواقع پروتکل بیت کوین حتی بدون هیچ گونه افزونه‌ای، نسخه ضعیفی از قرارداد های هوشمند را تسهیل میکند. UTXO در بیت کوین فقط با یک کلید عمومی مالکیت پیدا نمیکند، بلکه همچنین اسکریپت پیچیده تری در زبان برنامه نویسی بر پایه‌ی پشته‌ی ساده ابراز میشود. در این الگو، تراکنشی که آن UTXO را خرج میکند، باید داده هایی را فراهم کند که اسکریپت را قانع کند. در واقع حتی مکانیزم مالکیت کلید عمومی اصلی، از طریق یک اسکریپت پیاده می‌شود. این اسکریپت یک امضای منحنی بیضوی را به عنوان ورودی اعمال میکند که آن را در برابر تراکنش و آدرسی که مالک UTXO است، تایید میکند و اگر تایید موفق باشد، 1 و در غیر این صورت 0 ارجاع داده میشود. اسکریپت های پیچیده‌تر دیگری برای موارد استفاده اضافی متعددی موجود هستند. به عنوان مثال فرد میتواند اسکریپتی بسازد که نیازمند امضاهایی شامل دو از سه کلید خصوصی باشد تا اعتبارسنجی انجام شود. (multisig) این چیدمان برای اکانت های سازمانی، اکانت های پس انداز ایمن و موقعیت های شخص ثالث بازرگان، مفید است. اسکریپت ها همچنین می‌توانند برای پرداخت جایزه هایی که برای راه حل های محاسباتی داده میشوند، استفاده شوند و فرد میتواند حتی اسکریپتی بسازد که چیزی مانند این که UTXO بیت کوین متعلق به چه کسی است، نشان داده شود. اگر بتوان یک مدرک SPV فراهم کرد که فرد یک تراکنش دوج‌کوین را فرستاده است، در اساس این امر مجوز یک تراکنش متقابل غیر متمرکز رمزارز را میدهد.

اما زبان اسکریپت، آنچنان که در بیت کوین پیاده شده، محدودیت های مهمی هم دارد:

• عدم کامل بودن تورینگ - یعنی در حالی که زیرمجموعه بزرگی از محاسبات وجود دارد که زبان برنامه نویسی بیتکوین از آن پشتیبانی می کند، تقریباً همه چیز را پشتیبانی نمی کند. دسته اصلی که گم شده است حلقه ها هستند. این کار برای جلوگیری از حلقه های بی نهایت در حین تأیید تراکنش انجام می شود. از نظر تئوری، این یک مانع قابل عبور برای برنامه نویسان اسکریپت است، زیرا هر حلقه را می توان با تکرار چندین بار کد اصلی با یک دستور if شبیه سازی کرد، اما منجر به اسکریپت هایی می شود که بسیار کم فضا هستند. به عنوان مثال، اجرای یک الگوریتم امضای منحنی بیضوی جایگزین احتمالاً به 256 دور ضرب مکرر نیاز دارد که همه به صورت جداگانه در کد گنجانده شده است.
• کوری مقدار - هیچ راهی برای اسکریپت UTXO وجود ندارد که بتواند کنترل دقیقی بر مقدار قابل برداشت ارائه دهد. به عنوان مثال، یکی از موارد استفاده قدرتمند از یک قرارداد اوراکل، قرارداد پوشش ریسک است، که در آن A و B مقدار 1000 دلار بیتوین وارد می کنند و پس از 30 روز، اسکریپت 1000 دلار بیتکوین را به A و بقیه را به B ارسال می کند. اوراکل برای تعیین ارزش 1 بیتکوین به دلار آمریکا، اما حتی در آن زمان نیز از نظر اعتماد و نیاز به زیرساخت نسبت به راه حل های کاملاً متمرکزی که در حال حاضر در دسترس هستند، یک پیشرفت عظیم است. با این حال، از آنجایی که UTXO همه یا هیچ هستند، تنها راه برای دستیابی به این هدف از طریق هک بسیار ناکارآمد داشتن تعداد زیادی UTXO با ارزش‌های مختلف است (مثلاً یک UTXO از 2^k برای هر k تا 30) و اوراکل انتخاب کنید که کدام UTXO به A و کدام به B ارسال شود.
• عدم وضعیت - UTXO می تواند خرج شود یا خرج نشده باشد. هیچ فرصتی برای قراردادها یا قراردادهای چند امضایی وجود ندارد که هر حالت داخلی دیگری را فراتر از آن حفظ کند. این امر بستن قراردادهای گزینه‌های چند مرحله‌ای، پیشنهادها مبادله غیرمتمرکز یا پروتکل‌های تعهد رمزنگاری دو مرحله‌ای (ضروری برای پاداش‌های محاسباتی ایمن) را دشوار می‌کند. همچنین به این معنی است که UTXO فقط می‌تواند برای ایجاد قراردادهای ساده و یکبار استفاده شود و نه قراردادهای پیچیده‌تر مانند سازمان‌های غیرمتمرکز، و اجرای فراپروتکل‌ها را دشوار می‌کند. حالت دودویی همراه با ارزش کوری همچنین به این معنی است که یک برنامه مهم دیگر، محدودیت‌های برداشت، غیرممکن است.
• کوری بلاکچین - UTXO نسبت به داده هایبلاک چین مانند نانس، مهر زمانی و هش بلوک قبلی کور است. این امر با محروم کردن زبان برنامه‌نویسی از منبع بالقوه با ارزش تصادفی، برنامه‌های کاربردی در قمار و چندین دسته دیگر را به شدت محدود می‌کند.

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

اتریوم

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

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

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

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

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

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

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

واژه "تراکنش" در اتریوم برای اشاره به بسته داده امضا شده ای استفاده می شود که پیغامی را ذخیره می کند تا از یک حساب مالکیت خارجی ارسال شود. معاملات شامل:

• گیرنده پیام
• امضایی برای شناسایی فرستنده
• مقدار اتر برای انتقال از فرستنده به گیرنده
• یک فیلد داده اختیاری
• یک مقدار STARTGAS، نشان دهنده حداکثر تعداد مراحل محاسباتی است که اجرای تراکنش مجاز به انجام آن است
• مقدار GASPRICE، نشان دهنده هزینه ای است که فرستنده در هر مرحله محاسباتی می پردازد

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

فیلدهای STARTGAS و GASPRICE برای مدل ضد انکار خدمات اتریوم بسیار مهم هستند. به منظور جلوگیری از حلقه‌های نامحدود تصادفی یا متخاصم یا سایر اتلاف‌های محاسباتی در کد، هر تراکنش باید محدودیتی برای تعداد مراحل محاسباتی اجرای کد تعیین کند. واحد اساسی محاسبات "گس" است. معمولاً، یک مرحله محاسباتی 1 گس هزینه دارد، اما برخی از عملیات ها به دلیل اینکه از نظر محاسباتی گران‌تر هستند یا مقدار داده هایی را که باید به عنوان بخشی از حالت ذخیره شوند افزایش می دهند، مقدار گس بیشتری را هزینه می کنند. همچنین برای هر بایت در داده های تراکنش 5 گس کارمزد دریافت می شود. هدف سیستم کارمزد این است که از مهاجم بخواهد به ازای هر منبعی که مصرف می‌کند، از جمله محاسبات، پهنای باند و ذخیره‌سازی، به نسبت هزینه پرداخت کند. از این رو، هر تراکنشی که منجر به مصرف شبکه مقدار بیشتری از هر یک از این منابع شود، باید هزینه گس تقریباً متناسب با افزایش داشته باشد.

پیام‌ها

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

• فرستنده پیام (ضمنی)
• گیرنده پیام
• مقدار اتر برای انتقال در کنار پیام
• یک فیلد داده اختیاری
• یک مقدار STARTGAS

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

توجه داشته باشید که کمک هزینه گس تعیین شده توسط یک معامله یا قرارداد برای کل گس مصرف شده توسط آن معامله و کلیه اجراهای فرعی اعمال می شود. به عنوان مثال، اگر یک بازیگر خارجی A یک تراکنش را با 1000 گس به B ارسال کند، و B قبل از ارسال پیام به C، مقدار 600 گس مصرف کند، و اجرای داخلی C قبل از بازگشت، 300 گس مصرف کند، B می تواند قبل از تمام شدن گس 100 گس دیگر خرج کند.

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

تابع انتقال حالت اتریوم، APPLY(S,TX) -> S' را می توان به صورت زیر تعریف کرد:

1. بررسی کنید که آیا تراکنش به خوبی شکل گرفته است (یعنی تعداد مقادیر مناسبی دارد)، امضا معتبر است، و نانس با نانس در حساب فرستنده مطابقت دارد. اگر اینطور نیست، یک خطا بازگردان.
2. کارمزد تراکنش را به صورت STARTGAS * GASPRICE محاسبه کنید و آدرس ارسال را از روی امضا تعیین کنید. کارمزد را از موجودی حساب فرستنده کم کنید و نانس فرستنده را افزایش دهید. اگر موجودی کافی برای خرج کردن وجود ندارد، یک خطا را برگردان.
3. GAS = STARTGAS را راه‌اندازی کنید و مقدار مشخصی گس را در هر بایت بردارید تا هزینه بایت‌های موجود در تراکنش را بپردازید.
4. انتقال ارزش تراکنش از حساب فرستنده به حساب دریافت کننده. اگر حساب دریافت کننده هنوز وجود ندارد، آن را ایجاد کنید. اگر اکانت دریافت کننده قراردادی است، کد قرارداد را تا پایان یا تا زمانی که گس موجود است اجرا کن.
5. اگر انتقال ارزش به دلیل نداشتن پول کافی فرستنده انجام نشد، یا بنزین اجرای کد تمام شد، همه تغییرات حالت به جز پرداخت هزینه ها را برگردان و هزینه ها را به حساب ماینر اضافه کن.
6. در غیر این صورت، هزینه تمام گس باقیمانده را به فرستنده بازپرداخت کن و هزینه های پرداخت شده برای گس مصرف شده را برای ماینر ارسال کن.

به عنوان مثال، فرض کنید که کد قرارداد این است:

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

توجه داشته باشید که در واقع کد قرارداد در کد EVM سطح پایین نوشته شده است. این مثال برای وضوح در Serpent، یکی از زبان های سطح بالای ما، نوشته شده است و می توان آن را به کد EVM کامپایل کرد. فرض کنید ذخیره‌سازی قرارداد خالی شروع می‌شود و تراکنشی با 10 مقدار اتر، 2000 گس، 0.001 اتر قیمت گس و 64 بایت داده ارسال می‌شود، با بایت‌های 0-31 نشان دهنده عدد 2 و بایت است. 32-63 نشان دهنده رشته CHARLIE است. فرآیند تابع انتقال حالت در این مورد به شرح زیر است:

1. بررسی کنید که تراکنش معتبر و به خوبی شکل گرفته است.
2. بررسی کنید که فرستنده تراکنش حداقل 2000 * 0.001 = 2 اتر داشته باشد. اگر اینطور است، 2 اتر از حساب فرستنده کم کنید.
3. گس اولیه = 2000; با فرض اینکه تراکنش 170 بایت و هزینه بایت 5 باشد، 850 را کم کنید تا 1150 گس باقی بماند.
4. مقدار 10 اتر دیگر از حساب فرستنده کم کنید و آن را به حساب قرارداد اضافه کنید.
5. کد را اجرا کنید. GAS = STARTGAS را راه‌اندازی کنید و مقدار مشخصی از گس را در هر بایت برداشت تا هزینه بایت‌های موجود در تراکنش را بپردازید. فرض کنید این 187 گس می گیرد، بنابراین مقدار گس باقیمانده 1150 - 187 = 963 است
6. 963 * 0.001 = 0.963 اتر را دوباره به حساب فرستنده اضافه کنید و حالت حاصل را برگردانید.

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

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

اجرای کد

کد در قراردادهای اتریوم به زبان بایت کد مبتنی بر پشته، سطح پایین نوشته می شود که به آن «کد ماشین مجازی اتریوم» یا «کد EVM» گفته می شود. کد شامل یک سری بایت است که هر بایت نشان دهنده یک عملیات است. به طور کلی، اجرای کد یک حلقه بی نهایت است که شامل انجام مکرر عملیات در شمارنده برنامه فعلی (که از صفر شروع می شود) و سپس افزایش شمارنده برنامه به یک اندازه، تا رسیدن به انتهای کد یا یک خطا یا < دستورالعمل 0>STOP یا RETURN شناسایی شد. عملیات به سه نوع فضای ذخیره‌سازی داده‌ها دسترسی دارند:

• این پشته، محفظه‌ای که می‌توان آن‌ها را به بیرون فرستاد و مقادیر را به آن منتقل کرد
• Memory، یک آرایه بایت بی نهایت قابل گسترش است
• ذخیره طولانی مدت قرارداد، یک ذخیره از کلید/ارزش. برخلاف پشته و حافظه که پس از پایان محاسبات بازنشانی می‌شوند، ذخیره‌سازی برای طولانی مدت باقی می‌ماند.

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

مدل اجرای رسمی کد EVM به طرز شگفت آوری ساده است. در حالی که ماشین مجازی اتریوم در حال اجرا است، حالت محاسباتی کامل آن را می‌توان با چند (block_state، تراکنش، پیام، کد، حافظه، پشته، کامپیوتر، گس) تعریف کرد، جایی که block_state</ 0> حالت جهانی است که شامل تمام حساب ها و شامل موجودی ها و ذخیره‌سازی است. در شروع هر دور اجرا، دستورالعمل فعلی با گرفتن <code>pcامین بایت کد (یا 0 اگر pc >= len(code))، و هر دستورالعمل از نظر نحوه تأثیرگذاری بر تاپل، تعریف خاص خود را دارد. برای مثال، ADD دو مورد را از پشته بیرون می‌آورد و مجموع آنها را فشار می‌دهد، گس را به 1 کاهش می‌دهد و pc را به 1 افزایش می‌دهد و SSTORE دو مورد بالا را از پشته بیرون می‌آورد و مورد دوم را در فهرستی که مورد اول مشخص کرده است در محل ذخیره قرارداد قرار می‌دهد. اگرچه راه‌های زیادی برای بهینه‌سازی اجرای ماشین مجازی اتریوم از طریق کامپایل‌سازی به‌موقع وجود دارد، پیاده‌سازی اولیه اتریوم را می‌توان در چند صد خط کد انجام داد.

بلاک‌چین و ماینینگ

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

1. بررسی کنید که آیا بلوک قبلی ارجاع شده وجود دارد و معتبر است.
2. بررسی کنید که مهر زمانی بلوک بزرگتر از بلوک قبلی ارجاع شده و کمتر از 15 دقیقه در آینده باشد
3. بررسی کنید که شماره بلوک، سختی، ریشه تراکنش، ریشه عمو و محدودیت گس (مفاهیم مختلف سطح پایین ویژه اتریوم) معتبر هستند.
4. بررسی کنید که اثبات کار روی بلوک معتبر باشد.
5. حالت S[0] را حالت پایانی بلوک قبل بگذار.
6. اجازه دهید TX لیست تراکنش بلوک با n تراکنش باشد. برای همه iها در 0...n-1، S[i+1] = APPLY(S[i],TX[i]) را تنظیم کنید /0>. اگر هر برنامه‌ای خطایی را برمی‌گرداند، یا اگر کل گس مصرف‌شده در بلوک تا این نقطه از <code>GASLIMIT بیشتر شود، یک خطا را برگردانید.
7. بگذارید S_FINAL S[n] باشد، اما پاداش بلوک پرداختی به ماینر را اضافه کنید.
8. بررسی کنید که آیا ریشه درخت مرکل حالت S_FINAL با ریشه حالت نهایی ارائه شده در هدر بلوک برابر است یا خیر. اگر چنین باشد، بلوک معتبر است. در غیر این صورت معتبر نیست.

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

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

برنامه‌های کاربردی

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

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

سیستم‌های توکن درون بلاک‌چین کاربردهای زیادی دارند، از ارزهای فرعی که دارایی‌هایی مانند دلار یا طلا را نشان می‌دهند تا سهام شرکت، توکن‌های فردی که نشان دهنده دارایی هوشمند، کوپن‌های غیرقابل جعل امن و حتی سیستم‌های رمزی بدون هیچ ارتباطی با ارزش متعارف، به عنوان سیستم‌های نقطه‌ای برای ایجاد انگیزه استفاده می‌شوند. پیاده سازی سیستم های توکن در اتریوم به طرز شگفت انگیزی آسان است. نکته کلیدی برای درک این است که تمام یک ارز یا سیستم توکن، اساساً یک پایگاه داده با یک عملیات است: X واحدها را از A کم کنید و واحدهای X را به B بدهید، با این شرط که (i) A حداقل X واحد داشته باشد. قبل از تراکنش و (2) تراکنش توسط A تأیید شود. تمام آنچه برای پیاده سازی یک سیستم توکن نیاز است، پیاده سازی این منطق در یک قرارداد است.

کد اصلی برای پیاده سازی یک سیستم توکن در Serpent به صورت زیر است:

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

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

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

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

با توجه به آن عنصر حیاتی، قرارداد پوشش ریسک به شرح زیر است:

1. منتظر بمانید تا طرف اول 1000 اتر را وارد کند.
2. منتظر بمانید تا طرف دوم 1000 اتر را وارد کند.
3. ارزش دلاری 1000 اتر را که با کوئری زدن به قرارداد خوراک داده محاسبه می شود، در فضای ذخیره‌سازی ثبت کنید، بگویید این مقدار $x است.
4. پس از 30 روز، به طرف اول و دوم اجازه دهید تا قرارداد را "دوباره فعال کنند" تا اتر به ارزش $x (که با کوئری زدن مجدد به قرارداد خوراک داده برای دریافت قیمت جدید محاسبه می شود) به طرف اول و بقیه به طرف دوم ارسال شود.

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

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

سیستم های هویت و شهرت

اولین رمزارز جایگزین، Namecoin(opens in a new tab)، تلاش کرد از یک بلاکچین مانند بیتکوین برای ارائه یک سیستم ثبت نام استفاده کند، جایی که کاربران می توانند نام خود را در یک پایگاه داده عمومی در کنار سایر داده ها ثبت کنند. مورد استفاده عمده ذکر شده متعلق به یک سیستم DNS(opens in a new tab) است که نام های دامنه مانند "bitcoin.org" (یا در مورد Namecoin، "bitcoin.bit") را به یک آدرس IP نگاشت می کند. موارد استفاده دیگر عبارتند از احراز هویت ایمیل و سیستم های شهرت بالقوه پیشرفته‌تر. در اینجا قرارداد اصلی برای ارائه یک سیستم ثبت نام مشابه Namecoin در اتریوم است:

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

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

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

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

بخش کلیدی زیربنای چنین دستگاهی همان چیزی است که ما آن را "قرارداد غیرمتمرکز Dropbox" نامیده ایم. این قرارداد به شرح زیر عمل می کند. ابتدا، داده‌های مورد نظر را به بلوک‌ها تقسیم می‌کند، هر بلوک را برای حفظ حریم خصوصی رمزگذاری می‌کند و درخت مرکل را از آن می‌سازد. سپس یک قرارداد با این قانون منعقد می‌کند که، هر N بلوک، قرارداد یک شاخص تصادفی در درخت مرکل انتخاب می‌کند (با استفاده از هش بلوک قبلی، قابل دسترسی از کد قرارداد، به عنوان منبع تصادفی)، و X اتر را به اولین نهادی که یک تراکنش را با یک سند تأیید پرداخت ساده شده مبنی بر مالکیت بلوک در آن شاخص خاص در درخت ارائه می کند، می دهد. هنگامی که کاربر می خواهد فایل خود را دوباره دانلود کند، می تواند از پروتکل کانال پرداخت خرد (مثلاً پرداخت 1 زابو در هر 32 کیلوبایت) برای بازیابی فایل استفاده کند. کارآمدترین رویکرد این است که پرداخت کننده تراکنش را تا پایان منتشر نکند، در عوض تراکنش را با تراکنش کمی سودآورتر با همان نانس پس از هر 32 کیلوبایت جایگزین کند.

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

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

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

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

• [0,i,K,V] برای ثبت پیشنهاد با نمایه i برای تغییر آدرس در فهرست ذخیره‌سازی K به مقدار V
• برای ثبت رای به نفع پیشنهاد [1,i] i
• [2,i] برای نهایی کردن پیشنهاد i اگر رای کافی داده شده باشد

سپس قرارداد برای هر یک از اینها بندهایی خواهد داشت. این یک رکورد از همه تغییرات فضای باز را به همراه فهرستی از افرادی که به آنها رای داده اند حفظ می کند. همچنین فهرستی از همه اعضا را خواهد داشت. هنگامی که هر تغییر فضای ذخیره‌سازی به دو سوم اعضا می رسد که به آن رأی می دهند، یک تراکنش نهایی می تواند تغییر را اجرا کند. یک اسکلت پیچیده‌تر همچنین می‌تواند قابلیت رای‌گیری داخلی برای ویژگی‌هایی مانند ارسال تراکنش، افزودن اعضا و حذف اعضا داشته باشد، و حتی ممکن است امکان تفویض رأی به سبک دموکراسی نقد(opens in a new tab) را فراهم کند (یعنی هرکسی می‌تواند شخصی را به رای دادن به او اختصاص دهد، و انتساب انتقالی است، بنابراین اگر A به B و B به C اختصاص دهد، C رای A را تعیین می‌کند). این طراحی به DAO اجازه می دهد تا به صورت ارگانیک به عنوان یک جامعه غیرمتمرکز رشد کند، و به مردم این امکان را می دهد تا در نهایت وظیفه فیلتر کردن اعضای آن را به متخصصان محول کنند، اگرچه برخلاف «سیستم فعلی»، متخصصان به راحتی می توانند در طول زمان وارد و خارج شوند همانطور که افراد جامعه صف بندی خود را تغییر می دهند.

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

برنامه‌های کاربردهای بیشتر

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

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

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

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

3. یک خوراک دیتای غیرمتمرکز. برای قراردادهای مالی برای تفاوت، ممکن است واقعاً بتوان فید داده را از طریق پروتکلی به نام "SchellingCoin(opens in a new tab) غیرمتمرکز کرد". شلینگ کوین (SchellingCoin) اساساً به این صورت عمل می‌کند: N طرف همه ارزش یک داده معین (مثلاً قیمت اتر/USD) را در سیستم قرار می‌دهند، مقادیر مرتب می‌شوند، و هر کس بین صدک 25 و 75 یک توکن به عنوان پاداش دریافت می‌کند. همه انگیزه ای برای ارائه پاسخی دارند که دیگران ارائه خواهند کرد، و تنها ارزشی که تعداد زیادی از بازیکنان می توانند به طور واقع بینانه روی آن توافق کنند، پیش فرض آشکار است: حقیقت. این مورد یک پروتکل غیرمتمرکز ایجاد می‌کند که از نظر تئوری می‌تواند مقادیر زیادی از جمله قیمت اتر/USD، دمای برلین یا حتی نتیجه یک محاسبه سخت خاص را ارائه دهد.

4. ضمانت چند امضایی هوشمند. بیت‌کوین به قراردادهای تراکنش چند امضایی اجازه می‌دهد که برای مثال، سه کلید از پنج کلید معین می‌توانند وجوه را خرج کنند. اتریوم به جزئیات بیشتر اجازه می‌دهد. به عنوان مثال، از هر پنج نفر چهار نفر می‌توانند همه چیز را خرج کنند، از هر پنج نفر سه نفر می‌توانند تا 10 درصد در روز و از هر پنج نفر دو نفر می‌توانند تا 0.5 درصد در روز خرج کنند. علاوه بر این، اتریوم مالتی سیگ ناهمزمان است - دو طرف می‌توانند امضاهای خود را در زمان‌های مختلف روی بلاک‌چین ثبت کنند و آخرین امضا به طور خودکار تراکنش را ارسال می‌کند.

5. پردازش ابری. فناوری EVM همچنین می‌تواند برای ایجاد یک محیط محاسباتی قابل تأیید استفاده شود و به کاربران این امکان را می‌دهد که از دیگران بخواهند محاسبات را انجام دهند و سپس به‌صورت اختیاری، مدارکی بخواهند که محاسبات در نقاط بازرسی به‌طور تصادفی انتخاب شده به درستی انجام شده است. این مورد امکان ایجاد یک بازار رایانش ابری را فراهم می‌کند که در آن هر کاربر می‌تواند با دسکتاپ، لپ‌تاپ یا سرور تخصصی خود در آن شرکت کند و از چک کردن اسپات همراه با سپرده‌های امنیتی می‌توان برای اطمینان از قابل اعتماد بودن سیستم استفاده کرد (یعنی گره‌ها یا نودها نمی‌توانند به طور سودآوری تقلب کنند). اگرچه چنین سیستمی ممکن است برای همه کارها مناسب نباشد. به عنوان مثال، کارهایی که به سطح بالایی از ارتباطات بین فرآیندی نیاز دارند، نمی‌توانند به راحتی بر روی یک ابر بزرگ از گره‌ها یا نودها انجام شوند. با این حال، موازی سازی سایر وظایف بسیار آسان تر است. پروژه هایی مانند SETI@home، folding@home و الگوریتم های ژنتیک را می توان به راحتی بر روی چنین پلتفرمی پیاده‌سازی کرد.

6. قمار همتا به همتا. هر تعداد پروتکل قمار همتا به همتا مانند Cyberdice(opens in a new tab) Frank Stajano و Richard Clayton را می توان در بلاکچین اتریوم پیاده‌سازی کرد. ساده‌ترین پروتکل قمار در واقع صرفاً یک قرارداد برای تفاوت در هش بلوک بعدی است و پروتکل‌های پیشرفته‌تری را می‌توان از آنجا ایجاد کرد و خدمات قمار با هزینه‌های تقریباً صفر ایجاد کرد که توانایی تقلب ندارند.

7. بازارهای پیش بینی. به شرط یک اوراکل یا شلینگ کوین، پیاده‌سازی بازارهای پیش‌بینی نیز آسان است، و بازارهای پیش‌بینی همراه با شلینگ کوین ممکن است اولین کاربرد جریان اصلی futarchy(opens in a new tab) به عنوان پروتکل حاکمیتی برای سازمان‌های غیرمتمرکز باشد.

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

مسائل متفرقه و نگرانی‌ها

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

پروتکل "طماع‌ترین زیردرخت مشاهده شده" (GHOST) یک نوآوری است که برای اولین بار توسط Yonatan Sompolinsky و Aviv Zohar در دسامبر 2013(opens in a new tab) معرفی شد. انگیزه پشت GHOST این است که بلاک چین‌هایی با زمان تایید سریع در حال حاضر به دلیل نرخ قدیمی بالا از امنیت کمتری رنج می‌برند - زیرا بلوک‌ها زمان مشخصی را برای انتشار در شبکه می‌طلبند، اگر ماینر A یک بلوک را استخراج کند و سپس ماینر B بلوک دیگری را استخراج کند. قبل از انتشار بلوک ماینر A به B، بلوک ماینر B به هدر می رود و به امنیت شبکه کمک نمی کند. علاوه بر این، یک مشکل متمرکز وجود دارد: اگر ماینر A یک استخر استخراج با 30٪ قدرت هش و B دارای 10٪ قدرت هش باشد، A در 70٪ مواقع (از 30٪ بقیه مواقع) خطر تولید یک بلوک قدیمی را خواهد داشت. A آخرین بلوک را تولید می کند و بنابراین بلافاصله داده های استخراج را دریافت می کند) در حالی که B در 90٪ مواقع خطر تولید یک بلوک قدیمی را دارد. بنابراین، اگر فاصله بلوک به اندازه‌ای کوتاه باشد که نرخ بیات بالا باشد، A به‌دلیل اندازه‌اش به طور قابل‌توجهی کارآمدتر خواهد بود. با ترکیب این دو اثر، بلاکچین‌هایی که بلوک‌ها را به سرعت تولید می‌کنند، به احتمال زیاد منجر به یک استخر ماینینگ می‌شوند که درصد زیادی از قدرت هش شبکه را داشته باشد تا بتواند بالفعل بر فرآیند استخراج کنترل داشته باشد.

همانطور که توسط Sompolinsky و Zohar توضیح داده شد، GHOST اولین مشکل از دست دادن امنیت شبکه را با گنجاندن بلوک های قدیمی در محاسبه اینکه کدام زنجیره "طولانی ترین" است را حل می کند. به این معنا که نه تنها والدین و اجداد بعدی یک بلوک، بلکه نوادگان قدیمی اجداد بلوک (در اصطلاح اتریومی، "عمو ها") به محاسباتی اضافه می شوند که کدام بلوک دارای بزرگترین اثبات کار است. برای حل مسئله دوم سوگیری متمرکزسازی، ما فراتر از پروتکل توصیف شده توسط Sompolinsky و Zohar می‌رویم، و همچنین پاداش‌های بلوک را برای قدیمی‌ها ارائه می‌کنیم: یک بلوک قدیمی 87.5٪ از پاداش پایه خود را دریافت می‌کند و برادرزاده که شامل بلوک قدیمی است، 12.5 درصد بقیه را دریافت می‌کند. با این حال، کارمزد تراکنش به عموها تعلق نمی گیرد.

اتریوم نسخه ساده شده GHOST را پیاده سازی می کند که تنها در هفت سطح پایین می آید. به طور مشخص به صورت زیر تعریف می شود:

• یک بلوک باید یک والد را مشخص کند و باید 0 یا چند عمو را مشخص کند
• عموی موجود در بلوک B باید دارای ویژگی های زیر باشد:
  • این باید یک فرزند مستقیم از اجداد نسل k ام B باشد که در آن 2 <= k <= 7.
  • نمی تواند جد B باشد
  • عمو باید یک هدر بلوک معتبر باشد، اما نیازی نیست که قبلاً یک بلوک تأیید شده یا حتی معتبر باشد
  • یک عمو باید با همه عموهای موجود در بلوک های قبلی و سایر عموهای موجود در همان بلوک متفاوت باشد (غیر شامل دوگانه)
• به ازای هر عموی U در بلوک B، ماینر B 3.125٪ اضافی به پاداش کوین‌بیس خود اضافه می کند و ماینر U 93.75٪ از پاداش استاندارد کوین‌بیس را دریافت می کند.

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

کارمزدها

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

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

1. یک تراکنش به عملیات k منتهی می‌شود، و پاداش kR را به هر استخراج‌کننده‌ای که شامل آن می‌شود، ارائه می‌کند، جایی که R توسط فرستنده و k تنظیم شده است. و R از قبل (تقریبا) برای ماینر قابل مشاهده هستند.
2. یک عملیات دارای هزینه پردازش C برای هر گره است (یعنی همه گره ها کارایی یکسانی دارند)
3. تعداد N گره ماینینگ وجود دارد که هر کدام دقیقاً قدرت پردازشی برابری دارند (یعنی 1/N از کل)
4. هیچ گره کامل غیر ماینینگی وجود ندارد.

اگر پاداش مورد انتظار بیشتر از هزینه باشد، یک ماینر مایل به پردازش یک تراکنش است. بنابراین، پاداش مورد انتظار kR/N است زیرا ماینر شانس 1/N برای پردازش بلوک بعدی را دارد و هزینه پردازش برای ماینر به سادگی است. kC. بنابراین، ماینرها شامل تراکنش‌هایی می‌شوند که در آنها kR/N > kC، یا R > NC باشد. توجه داشته باشید که R کارمزد هر عملیات ارائه شده توسط فرستنده است، و بنابراین یک حد پایین‌تر برای سودی است که فرستنده از تراکنش کسب می‌کند،و NC هزینه کل شبکه برای پردازش یک عملیات است. از این رو، ماینرها این انگیزه را دارند که فقط آن دسته از تراکنش‌هایی را بگنجانند که کل سود از هزینه آن بیشتر باشد.

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

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

(1) تمایلی را برای ماینر فراهم می کند که تراکنش های کمتری را شامل شود، و (2) NC را افزایش می دهد. بنابراین، این دو اثر حداقل تا حدی یکدیگر را خنثی می کنند.^{[چگونه؟] https://github.com/ethereum/wiki/issues/447#issuecomment-316972260(opens in a new tab))} (3) و (4) موضوع اصلی هستند. برای حل آنها به سادگی یک سرمایه شناور ایجاد می کنیم: هیچ بلوکی نمی تواند بیش از BLK_LIMIT_FACTOR برابر میانگین متحرک نمایی بلندمدت عملیات داشته باشد. به خصوص:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR و EMA_FACTOR ثابت‌هایی هستند که فعلاً روی 65536 و 1.5 تنظیم می‌شوند، اما احتمالاً پس از تجزیه و تحلیل بیشتر تغییر خواهند کرد.

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

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

یک نکته مهم این است که ماشین مجازی اتریوم تورینگ کامل است. این بدان معنی است که کد EVM می تواند هر محاسباتی را که می توان انجام داد، از جمله حلقه های بی نهایت، رمزگذاری کند. کد EVM به دو صورت امکان حلقه زدن را می دهد. اول، یک دستورالعمل JUMP وجود دارد که به برنامه اجازه می دهد به نقطه قبلی در کد بازگردد، و یک دستور JUMPI برای انجام پرش شرطی، اجازه می دهد تا عباراتی مانند در حالی که x < 27: x = x * 2 است. دوم، قراردادها می‌توانند قراردادهای دیگری را فراخوانی کنند، که امکان چرخش از طریق بازگشت را فراهم می‌کند. این مورد به طور طبیعی منجر به یک مشکل می‌شود: آیا کاربران مخرب اساساً می‌توانند ماینرها و گره یا نودهای کامل را با مجبور کردن آنها برای ورود به یک لوپ (loop) بی‌نهایت ببندند؟ این موضوع به دلیل مشکلی در علم کامپیوتر به نام مشکل توقف به وجود می‌آید: در حالت کلی، هیچ راهی برای تشخیص اینکه آیا یک برنامه مشخص هرگز متوقف می‌شود یا خیر وجود ندارد.

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

• یک مهاجم قراردادی ایجاد می‌کند که یک حلقه بی‌نهایت اجرا می‌کند، و سپس یک تراکنش فعال‌سازی آن حلقه را برای ماینر ارسال می‌کند. ماینر تراکنش را پردازش می کند، حلقه بی نهایت را اجرا می کند و منتظر می ماند تا گس آن تمام شود. حتی اگر گس اجرا تمام شود و در نیمه راه متوقف شود، تراکنش هنوز معتبر است و ماینر همچنان هزینه هر مرحله محاسباتی را از مهاجم مطالبه می کند.
• یک مهاجم یک حلقه بینهایت بسیار طولانی ایجاد می کند که قصد دارد ماینر را مجبور کند که محاسبات را برای مدت طولانی ادامه دهد تا زمانی که محاسبات به پایان برسد، چند بلوک دیگر بیرون آمده و برای ماینر امکان گنجاندن تراکنش برای مطالبه کارمزد وجود نخواهد داشت. با این حال، مهاجم باید مقداری را برای STARTGAS ارسال کند که تعداد مراحل محاسباتی را که اجرا می‌تواند انجام دهد محدود می‌کند. بنابراین ماینر از قبل می‌داند که محاسبه تعداد بسیار زیادی از مراحل را طی می‌کند.
• مهاجم قراردادی را با کدهایی مانند send(A,contract.storage[A]) می بیند. contract.storage[A] = 0، و تراکنش را با گس کافی برای اجرای مرحله اول ارسال می کند اما مرحله دوم را نه (یعنی برداشت انجام می دهد اما اجازه نمی دهد موجودی پایین بیاید). نویسنده قرارداد نیازی به نگرانی در مورد محافظت در برابر چنین حملاتی ندارد، زیرا اگر اجرا در نیمه راه متوقف شود، تغییرات برگردانده می شوند.
• یک قرارداد مالی با استفاده از میانه 9 خوراک دیتای اختصاصی به منظور به حداقل رساندن ریسک کار می کند. مهاجم یکی از فیدهای داده را در اختیار می گیرد که به گونه ای طراحی شده است که از طریق مکانیسم متغیر-آدرس-فراخوانی توضیح داده شده در بخش DAO قابل تغییر باشد، و آن را به یک حلقه بی نهایت تبدیل می کند، در نتیجه تلاش می کند هر گونه تلاش برای مطالبه وجوه از قرارداد مالی را مجبور به تمام شدن گاز کند. با این حال، قرارداد مالی می تواند برای جلوگیری از این مشکل محدودیتی برای پیام تعیین کند.

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

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

اکنون یک تراکنش به A ارسال کنید. بنابراین، در 51 تراکنش، قراردادی داریم که 2⁵⁰ مرحله محاسباتی را طی می کند. ماینرها می‌توانند با حفظ مقداری در کنار هر قرارداد که حداکثر تعداد مراحل محاسباتی را که می‌تواند انجام دهد، این بمب‌های منطقی را پیش از موعد شناسایی کنند، و محاسبه این برای قراردادهایی که قراردادهای دیگر را به صورت بازگشتی فراخوانی می‌کنند، اما این امر مستلزم آن است که ماینرها قراردادهایی را که قراردادهای دیگری ایجاد می‌کنند ممنوع کنند (از آنجایی که ایجاد و اجرای تمام 26 قرارداد فوق به راحتی می تواند در یک قرارداد واحد تبدیل شود). نکته مشکل‌ساز دیگر این است که فیلد آدرس یک پیام یک متغیر است، بنابراین به طور کلی ممکن است حتی نتوان گفت که یک قرارداد معین با کدام قراردادهای دیگر پیش از موعد تماس خواهد گرفت. بنابراین، در مجموع، ما یک نتیجه شگفت‌انگیز داریم: مدیریت کامل بودن تورینگ به‌طور شگفت‌انگیزی آسان است، و مدیریت عدم وجود تورینگ کامل بودن به همان اندازه دشوار است، مگر اینکه دقیقاً همان کنترل‌ها وجود داشته باشد - اما در این مورد چرا نه فقط اجازه دهید پروتکل تورینگ کامل باشد?

ارز و صدور

شبکه اتریوم شامل ارز داخلی خود به نام اتر است که هدف دوگانه ارائه یک لایه نقدینگی اولیه را برای تبادل کارآمد بین انواع مختلف دارایی‌های دیجیتال و مهمتر از آن، ارائه مکانیزمی برای پرداخت هزینه تراکنش‌ها دارد. برای سهولت و اجتناب از استدلال های آینده (به بحث فعلی mBTC/uBTC/satoshi در بیتکوین مراجعه کنید)، مقادیر ارزش از قبل نامگذاری گذاری خواهند شد:

• 1: wei
• 10¹²: szabo
• 10¹⁵: finney
• 10¹⁸: ether

این باید به عنوان یک نسخه توسعه یافته از مفهوم "دلار" و "سنت" یا "بیت‌کوین" و "ساتوشی" در نظر گرفته شود. در آینده نزدیک، ما انتظار داریم که "اتر" برای تراکنش های معمولی، "finney" برای تراکنش های خرد و "szabo" و "wei" برای بحث های فنی در مورد هزینه ها و اجرای پروتکل استفاده شود. ارزش‌های باقی‌مانده ممکن است بعداً مفید باشند و در این مرحله نباید در مشتریان گنجانده شوند.

مدل صدور به صورت زیر خواهد بود:

• اتر در فروش ارزی با قیمت 1000 تا 2000 اتر در هر بیت‌کوین عرضه خواهد شد، مکانیزمی که برای تامین مالی سازمان اتریوم و پرداخت هزینه توسعه در نظر گرفته شده است که با موفقیت توسط پلتفرم‌های دیگری مانند مسترکوین (Mastercoin) و NXT استفاده شده است. خریداران اولیه از تخفیف‌های بیشتری بهره‌مند خواهند شد. بیت کوین دریافتی از فروش کامل برای پرداخت حقوق و جوایز به توسعه‌دهندگان و سرمایه‌گذاری در پروژه‌های مختلف انتفاعی و غیرانتفاعی در اتریوم و اکوسیستم ارزهای دیجیتال استفاده می‌شود.
• 0.099 برابر کل مبلغ فروخته شده (60102216 اتر) برای جبران خسارت مشارکت‌کنندگان اولیه و پرداخت هزینه‌های اتر قبل از بلوک پیدایش به سازمان تخصیص داده می‌شود.
• 0.099 برابر کل مبلغ فروخته شده به عنوان ذخیره بلند مدت نگهداری می‌شود.
• 0.26 برابر کل مبلغ فروخته شده برای همیشه پس از آن نقطه به ماینرها در سال اختصاص می یابد.

نرخ رشد عرضه بلندمدت (درصد)

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

دو انتخاب اصلی در مدل فوق عبارتند از (1) وجود و اندازه یک استخر وقف، و (2) وجود یک عرضه خطی دائما در حال رشد، در مقابل عرضه سقفی مانند بیتکوین. توجیه استخر وقف به شرح زیر است. اگر استخر وقف وجود نداشت، و انتشار خطی به 0.217 برابر کاهش می یافت تا نرخ تورم یکسانی ارائه شود، آنگاه مقدار کل اتر 16.5٪ کمتر می شد و بنابراین هر واحد 19.8٪ ارزش بیشتری داشت. بنابراین، در حالت تعادل 19.8٪ اتر بیشتر در فروش خریداری می شود، بنابراین هر واحد دوباره دقیقاً به اندازه قبل ارزشمند خواهد بود. این سازمان همچنین 1.198 برابر همان بیتکوین خواهد داشت که می توان آن را به دو بخش تقسیم کرد: بیتکوین اصلی و 0.198 برابر دیگر. از این رو، این وضعیت دقیقاً معادل با وقف است، اما با یک تفاوت مهم: سازمان صرفاً BTC را در اختیار دارد، و بنابراین انگیزه ای برای حمایت از ارزش واحد اتر ندارد.

مدل رشد عرضه خطی دائمی خطر آنچه را که برخی به عنوان تمرکز بیش از حد ثروت در بیتکوین می دانند، کاهش می دهد. و به افرادی که در دوران کنونی و آینده زندگی می کنند فرصت مناسبی برای بدست آوردن واحدهای ارزی می دهد، در حالی که در عین حال انگیزه قوی برای به دست آوردن و نگهداری اتر حفظ می شود زیرا "نرخ رشد عرضه" به عنوان درصد همچنان در طول زمان به صفر تمایل دارد. ما همچنین این نظریه را مطرح می کنیم که چون سکه ها همیشه در طول زمان به دلیل بی احتیاطی، مرگ و غیره گم می شوند، و زیان سکه را می توان به صورت درصدی از کل عرضه در سال مدل کرد، که در واقع عرضه کل ارز در گردش در نهایت در ارزشی برابر با انتشار سالانه تقسیم بر نرخ ضرر تثبیت می شود. (به عنوان مثال، با نرخ ضرر 1٪، هنگامی که عرضه به 26X رسید، 0.26X استخراج می شود و 0.26X هر سال از دست می رود و تعادل ایجاد می کند).

توجه داشته باشید که در آینده، این احتمال وجود دارد که اتریوم برای امنیت به مدل اثبات سهام روی بیاورد و نیاز صدور را بین صفر تا 0.05 برابر در سال کاهش دهد. در صورتی که سازمان اتریوم بودجه خود را از دست بدهد یا به هر دلیل دیگری ناپدید شود، یک "قرارداد اجتماعی" را باز می گذاریم: هر کسی حق دارد یک نسخه کاندید آینده اتریوم ایجاد کند، تنها شرط این است که مقدار اتر باید حداکثر برابر با 60102216 * (1.198 + 0.26 * n) باشد که در آن n تعداد سال‌های پس از بلوک پیدایش است. سازندگان مختارند که به صورت انبوه بفروشند یا برخی یا تمام تفاوت بین گسترش عرضه مبتنی بر PoS و حداکثر گسترش عرضه مجاز را برای پرداخت هزینه توسعه اختصاص دهند. نامزدهای ارتقا که با قرارداد اجتماعی مطابقت ندارند، ممکن است به طور موجه در نسخه های سازگار تقسیم شوند.

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

الگوریتم استخراج بیتکوین به این صورت کار می کند که ماینرها SHA256 را بر روی نسخه های کمی تغییر یافته هدر بلوک میلیون ها بار و بارها محاسبه کنند تا اینکه در نهایت یک گره نسخه ای را ارائه می دهد که هش آن کمتر از هدف است (در حال حاضر حدود 2¹⁹² ). با این حال، این الگوریتم استخراج در برابر دو شکل از تمرکزگرایی آسیب پذیر است. اول، اکوسیستم ماینینگ تحت تسلط ASIC ها (مدارهای مجتمع ویژه برنامه)، تراشه های کامپیوتری طراحی شده و در نتیجه هزاران بار کارآمدتر در وظایف خاص استخراج بیتکوین قرار گرفته است. این به این معنی است که استخراج بیتکوین دیگر یک پیگیری بسیار غیرمتمرکز و برابری طلبانه نیست و برای مشارکت موثر در آن به میلیون ها دلار سرمایه نیاز دارد. دوم، اکثر ماینرهای بیتکوین در واقع اعتبارسنج بلوک را به صورت محلی انجام نمی دهند. در عوض، آنها به یک استخر استخراج متمرکز برای ارائه هدرهای بلوک متکی هستند. این مشکل مسلماً بدتر است: تا زمان نگارش این مقاله، سه استخر استخراج برتر به طور غیرمستقیم تقریباً 50 درصد از قدرت پردازش در شبکه بیتکوین را کنترل می‌کنند، اگر چه اگر یک استخر یا ائتلاف حمله ای 51 درصدی انجام دهد، این امر با این واقعیت کاهش می یابد که ماینرها می توانند به استخرهای استخراج دیگر روی آورند.

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

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

قابل مقیاس

یکی از نگرانی‌های رایج در مورد اتریوم مسئله مقیاس‌پذیری است. مانند بیت‌کوین، اتریوم نیز از این نقص رنج می‌برد که هر تراکنش باید توسط هر گره یا نود در شبکه پردازش شود. با بیت‌کوین، اندازه بلاک‌چین فعلی در حدود 15 گیگابایت است که حدود 1 مگابایت در ساعت افزایش می‌یابد. اگر شبکه بیت‌کوین 2000 تراکنش ویزا را در ثانیه پردازش کند، 1 مگابایت در هر سه ثانیه (1 گیگابایت در ساعت، 8 ترابایت در سال) رشد می‌کند. اتریوم احتمالاً از الگوی رشد مشابهی رنج می‌برد، که با این واقعیت بدتر شده است که برنامه‌های کاربردی زیادی بر روی بستر بلاکچین اتریوم به جای ارز مانند بیتکوین وجود خواهد داشت، اما با این واقعیت که گره های کامل اتریوم به جای کل تاریخچه بلاکچین، فقط وضعیت را ذخیره می کنند، بهبود یافته است.

مشکل چنین اندازه بلاکچین بزرگی، ریسک تمرکزگرایی است. اگر اندازه بلاکچین به مثلاً 100 ترابایت افزایش یابد، سناریوی محتمل این خواهد بود که تنها تعداد بسیار کمی از کسب‌وکارهای بزرگ گره‌های کامل را اجرا کنند و همه کاربران عادی از گره‌های SPV سبک استفاده کنند. در چنین شرایطی، این نگرانی وجود دارد که گره‌ یا نودهای کامل می‌توانند به یکدیگر متصل شوند و همه توافق کنند که به شیوه‌ای سودآور تقلب کنند (مثلاً پاداش بلوک را تغییر دهند، به خود بیت‌کوین بدهند). گره های سبک هیچ راهی برای تشخیص فوری این موضوع ندارند. البته، حداقل یک گره کامل صادقانه احتمالا وجود خواهد داشت، و پس از چند ساعت اطلاعات مربوط به کلاهبرداری از طریق کانال‌هایی مانند ردیت منتشر می‌شود، اما در آن مرحله دیگر خیلی دیر شده است: این ساماندهی بر عهده کاربران عادی است که تلاشی را برای فهرست سیاه بلوک های داده شده سازماندهی کنند، یک مشکل هماهنگی عظیم و احتمالا غیرقابل اجرا در مقیاسی مشابه با انجام یک حمله موفق 51 درصدی. در مورد بیتکوین، این در حال حاضر یک مشکل است، اما یک اصلاح بلاکچینی پیشنهاد شده توسط پیتر تاد(opens in a new tab) وجود دارد که این مشکل را کاهش می دهد.

در کوتاه مدت، اتریوم از دو استراتژی اضافی برای مقابله با این مشکل استفاده خواهد کرد. اولاً، به دلیل الگوریتم‌های استخراج مبتنی بر بلاکچین، حداقل هر ماینر مجبور می‌شود که یک گره کامل باشد و یک حد پایین‌تر برای تعداد گره‌های کامل ایجاد کند. دوم و مهمتر، با این حال، ما پس از پردازش هر تراکنش، یک ریشه درخت حالت میانی را در بلاکچین قرار می دهیم. حتی اگر اعتبار سنجی بلوک متمرکز باشد، تا زمانی که یک گره یا نود راستی‌آزمایی صادقانه وجود داشته باشد، مشکل متمرکزسازی را می‌توان از طریق یک پروتکل تأیید دور زد. اگر یک ماینر یک بلوک نامعتبر منتشر کند، آن بلوک یا باید بد قالب باشد یا وضعیت S[n] نادرست است. از آنجایی که S[0] به عنوان صحیح شناخته شده است، باید اولین حالت S[i] وجود داشته باشد که در جایی که S[i-1]</> نادرست است 0> صحیح است. گره تأیید کننده شاخص <code>i را به همراه یک "اثبات عدم اعتبار" شامل زیرمجموعه گره های درخت پاتریشیا که نیاز به پردازش APPLY(S[i-1],TX[i) را ارائه می کند.]) -> S[i]. گره ها می توانند از آن گره ها برای اجرای آن قسمت از محاسبات استفاده کنند و ببینند که S[i] تولید شده با S[i] ارائه شده مطابقت ندارد.

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

نتيجه گيری

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

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

یادداشت ها و مطالعه بیشتر

یادداشت ها

1. یک خواننده آگاه ممکن است متوجه شود که در واقع یک آدرس بیتکوین هش کلید عمومی منحنی بیضوی است و نه خود کلید عمومی. با این حال، در واقع اصطلاحات رمزنگاری کاملاً قانونی است که به هش پابکی (pubkey) به عنوان خود کلید عمومی اشاره شود. این به این دلیل است که رمزنگاری بیتکوین را می توان یک الگوریتم امضای دیجیتال سفارشی در نظر گرفت، که در آن کلید عمومی از هش کلید pubkey ECC تشکیل شده است، امضا شامل کلید pubkey ECC است که با امضای ECC پیوند خورده است. و الگوریتم تأیید شامل بررسی ECC pubkey در امضا در برابر هش ECC pubkey ارائه شده به عنوان کلید عمومی و سپس تأیید امضای ECC در برابر کلید pubkey ECC است.
2. از نظر فنی، میانه 11 بلوک قبلی.
3. از نظر داخلی، 2 و "CHARLIE" هر دو اعداد هستند^fn3، که دومی در نمایش پایه 256 بیگ ایندین قرار دارد. اعداد می توانند حداقل 0 و حداکثر 2²⁵⁶-1 باشند.

اطلاعات بیشتر

1. ارزش ذاتی(opens in a new tab)
2. دارایی هوشمند(opens in a new tab)
3. قرارداد‌های هوشمند(opens in a new tab)
4. B-money(opens in a new tab)
5. شواهد کار قابل استفاده مجدد(opens in a new tab)
6. عناوین ملکی را با اختیار مالک تضمین کنید(opens in a new tab)
7. برگه سفید بیت کوین(opens in a new tab)
8. Namecoin(opens in a new tab)
9. مثلت زوکو(opens in a new tab)
10. وایت پیپر سکه‌های رنگی(opens in a new tab)
11. وایت پیپر مسترکوین(opens in a new tab)
12. شرکت های مستقل غیرمتمرکز، مجله بیت کوین(opens in a new tab)
13. تأیید پرداخت ساده(opens in a new tab)
14. درختان مرکل(opens in a new tab)
15. درختان پاتریشیا(opens in a new tab)
16. GHOST(opens in a new tab)
17. StorJ و ایجنت های خودمختار، جف گارزیک(opens in a new tab)
18. مایک هرن در مورد املاک هوشمند در جشنواره تورینگ(opens in a new tab)
19. Ethereum RLP(opens in a new tab)
20. درخت مرکل پاتریشیا اتریوم(opens in a new tab)
21. پیتر تاد درباره درختان مرکل(opens in a new tab)

برای تاریخچه وایت پیپر، این ویکی(opens in a new tab) را ببینید.

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