اوراق سفید(White Paper) اتریوم (Ethereum)

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

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

توسعه و انتشار بیت کوین ساتوشی ناکاموتو در سال 2009 اغلب به عنوان تحول بنیادی پول و ارز شناخته می شود ، این اولین نمونه از دارایی دیجیتال بود که به طور همزمان هیچ پشتیانی یا ارزش ذاتی ندارد و هیچ صادر کننده یا کنترل کننده متمرکزی ندارد. با این حال ، یک بخش دیگر (واحتمالا مهمتر) از ارز بیت کوین این است که فناوری بنیادی بلاکچین به عنوان ابزاری برای توافق عمومی شده است و تمامی توجه ها به سرعت در حال معطوف شدن به این جنبه دیگر بیت کوین است. کاربردهای جایگزین متداول فناوری بلاکچین شامل استفاده از دارایی های دیجیتال بلاکچین برای ارائه دادن ارزهای سفارشی و ابزارهای مالی، مالکیت یک دستگاه فیزیکی بنیادی (دارایی هوشمند) ، دارایی های غیرقابل سرهم مانند نام دامنه (Namecoin) ، و همچنین برنامه های پیچیده تر شامل کنترل مستقیم دارایی های دیجیتال توسط یک قطعه کد اجرای قوانین دلخواه (قراردادهای هوشمند) یا حتی سازمانهای مستقل غیر متمرکز مبتنی بر بلاکچین (DAO) است. آنچه اتریوم قصد دارد ارائه دهد بلاک چینی با یک زبان برنامه نویسی کاملاً داخلی است که می تواند برای ایجاد “قراردادها” استفاده شود و همچنین می تواند برای رمزگذاری توابع انتقال حالت دلخواه مورد استفاده قرار گیرد که به کاربران اجازه می دهد هر یک از سیستم های توضیح داده شده در بالا را ایجاد کنند ، و همچنین بسیاری  کارهای دیگر را که ما هنوز نمیتوانیم تصور کنیم به سادگی و با نوشتن منطق در چند سطر کد انجام می دهد.

 

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

تاریخچه

مفهوم ارز دیجیتال غیرمتمرکز ، و همچنین برنامه های کاربردی جایگزین مانند ثبت املاک ، برای دهه ها وجود داشته است. پروتکل های ناشناخته پول نقد الکترونیکی در دهه 1980 و 1990 ، بیشتر متکی به یک نسخه رمزنگاری معروف به کور شدن Chaumian بود که ارز با درجه بالایی از حریم خصوصی را فراهم می کرد ، اما این پروتکل ها به دلیل اتکا به واسطه متمرکز تا حد زیادی نتوانستند مورد توجه قرار گیرند. در سال 1998 وی دای، با معرفی b money به اولین پیشنهاد کننده ایده خلق پول از طریق حل معماهای محاسباتی و همچنین اجماع غیرمتمرکز تبدیل شد، اما این پیشنهاد در مورد جزئیات چگونگی اجرای اجماع غیرمتمرکز واقعاً دارای کاستی بود. در سال 2005 ، هال فینی مفهومی از گواه اثبات کار(pow) قابل استفاده مجدد را ارائه داد ، سیستمی که از ایده های b-money همراه با پازل های هش کش محاسباتی Adam Back برای ایجاد مفهومی برای ارز رمزپایه استفاده می کند ، اما یک بار دیگر با اتکا بر محاسبات قابل اعتماد به عنوان یک بک اند به میزان ایده آل دست نیافت. در سال 2009 ، یک ارز غیرمتمرکز برای اولین بار توسط Satoshi Nakamoto در عمل اجرا شد ، که ترکیبی از مبانی اولیه برای مدیریت مالکیت از طریق رمزنگاری کلید عمومی با یک الگوریتم اجماع برای پیگیری مالکیت سکه ها است،بود که به عنوان “اثبات کار” شناخته می شود.

مکانیسم پشت پرده اثبات کار یک پیشرفت مهم در فضا بود زیرا همزمان دو مشکل را حل می کرد. اول اینکه  یک الگوریتم اجماع ساده و نسبتاً موثر را ارائه داد ، که به گره های شبکه امکان می دهد تا در مورد مجموعه ای از به روزرسانی های متعارف وضعیت دفتر کل بیت کوین به توافق برسند. دوم این که سازوكاری را برای اجازه ورود آزاد به روند آرای عمومی ، حل مسئله سیاسی تصمیم گیری در مورد تأثیرگذاری بر آرای عمومی ، ضمن جلوگیری از حملات سیبیل ، فراهم كرد. این کار را با جایگزینی یک مانع رسمی در مشارکت ، مانند نیاز به ثبت به عنوان یک نهاد منحصر به فرد در یک لیست خاص ، با یک مانع اقتصادی انجام می دهد – وزن یک گره در روند رای گیری اجماع مستقیماً با قدرت محاسبه که گره به ارمغان می آورد متناسب است. از آن زمان ، روش دیگری تحت عنوان “اثبات سهام” که شامل محاسبه وزن یک گره متناسب با دارایی های ارزی آن و نه منابع محاسباتی است ، ارائه شده است. بحث در مورد شایستگی های نسبی این دو روش فراتر از محدوده این مقاله است اما باید توجه داشت که هر دو روش می تواند به عنوان ستون فقرات یک ارز رمزپایه استفاده شود.

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

از نقطه نظر فنی ، یک ارز رمزنگاری شده مانند بیت کوین را می توان به عنوان یک سیستم انتقال حالت در نظر گرفت ، جایی که یک “حالت” وجود دارد که شامل وضعیت مالکیت تمام بیت کوین های موجود و “عمل انتقال حالت” است که یک حالت را می گیرد و یک معامله و یک حالت جدید را به عنوان نتیجه تولید می کند. به عنوان مثال ، در یک سیستم بانکی استاندارد ، “حالت” یک ترازنامه است و “معامله” درخواست انتقال $ X از A به B است ، در اینجا “عمل انتقال حالت” مقدار حساب A را به میزان$ X کاهش می دهد و ارزش را در حساب B به میزان $ X افزایش می دهد. اگر حساب A در وهله اول کمتر از $ 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 بایتی که در واقع یک کلید عمومی رمزنگاری است(نکته1)). یک تراکنش شامل یک یا چند ورودی است که هر ورودی شامل ارجاع به UTXO موجود و یک امضای رمزنگاری است که توسط کلید خصوصی مرتبط با آدرس مالک تولید می شود و یک یا چند خروجی ، که هر خروجی حاوی UTXO جدید است.

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

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

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

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

فرض کنید آلیس می خواهد 11.7 بیت کوین را برای باب ارسال کند. اول ، آلیس به دنبال مجموعه ای از UTXO موجود است که متعلق به خودش است و حداقل تا 11.7 بیت کوین می ارزد. در واقع ، آلیس قادر به دریافت دقیقاً 11.7 بیت کوین نخواهد بود. می توان گفت که کوچکترین چیزی که او می تواند کسب کند 6 + 4 + 2 = 12 است. سپس با آن سه ورودی و دو خروجی یک تراکنش ایجاد می کند. اولین خروجی 11.7 بیت کوین با آدرس باب به عنوان صاحب آن خواهد بود و خروجی دوم 0.3 باقیمانده “خورده” بیت کوین خواهد بود که مالک آن خود آلیس است.

استخراج

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

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

  1. بررسی کنید آیا بلوک قبلی که ازاین بلوک منشا گرفته است معتبر است یا خیر.
  2. بررسی کنید که برچسب زمان(تایم استمپ) بلوک مورد نظر از بلوک قبلی بیشتر و از دو ساعت آینده کمتر باشد.(نکته2)
  3. بررسی کنید که “اثبات کار” در بلوک معتبر است.
  4. بگذارید S[0] حالت آخر بلوک قبلی باشد.
  5. فرض کنید TX لیست معاملات بلوک با n تراکنش است. برای همه i در 0 … n-1 ،

(S[i],TX[i]) مجموع S[i+1]= را تنظیم کنید و اگر هر برنامه ای خطایی داد خارج شوید و اشتباه را تصحیح کنید.

  1. true را برگردانید و S[n] را به عنوان وضعیت انتهای این بلوک ثبت کنید.

اساساً ، هر معامله در بلوک باید یک انتقال حالت معتبر را از حالت متعارف پیش از اجرای معامله ،به حالت جدید فراهم کند. توجه داشته باشید که حالت به هیچ وجه در بلوک رمزگذاری نشده است. صرفاً یک چکیده است که توسط گره اعتبارسنجی به خاطر سپرده می شود و فقط با شروع از حالت اصلی و اعمال متوالی هر معامله در هر بلوک (به صورت ایمن) برای هر بلوک قابل محاسبه است. علاوه بر این ، توجه داشته باشید که ترتیب معاملات یک ماینر در بلوک مهم است. اگر دو معامله A و B در یک بلوک وجود داشته باشد به گونه ای که B یک UTXO ایجاد شده توسط A را خرج کند ، تنها در صورتی که A قبل از B قرار بگیرد بلوک معتبر خواهد بود.

یک شرط اعتبار موجود در لیست فوق که در سیستم های دیگر یافت نمی شود ، شرط “اثبات کار” است. شرط دقیق این است که هش دوبل SHA256 از هر بلوک ، که به عنوان یک عدد 256 بیتی در نظر گرفته می شود ، باید کمتر از یک هدف تنظیم شده پویا باشد ، که از زمان نوشتن این مقاله تقریبا 2 به توان 187 است. هدف در اینجا این است که ماهیت بلوک را از نظر محاسباتی “سخت” کنیم، تا در نتیجه بتوانیم از بازسازی کل بلاکچین به نفع خود توسط مهاجمین sybil جلوگیری کنیم. از آنجا که SHA256 به عنوان یک تابع شبه تصادفی کاملاً غیرقابل پیش بینی طراحی شده است ، تنها راه ایجاد یک بلوک معتبر صرفاً آزمایش و خطا است که به طور مکرر باعث افزایش nonce می شود و مطابقت هش جدید را بررسی می کند. با هدف فعلی 2 به توان 187، شبکه باید به طور متوسط ​​ 2 به توان 69 بار تلاش کند تا بتواند یک بلوک معتبر پیدا کند. به طور کلی ، تارگت در هر 2016 بلوک در میان دوباره تنظیم می شود به گونه ای که به طور متوسط ​​هر ده دقیقه یک بلوک جدید توسط برخی از گره های شبکه تولید می شود. برای جبران خسارت این کار محاسباتی به استخراج کنندگان ، استخراج کننده هر بلوک حق دارد معامله ای را انجام دهد که 12.5 بیت کوین رایگان به خودشان بدهد. علاوه بر این ، اگر هر معامله در کل ورودی های بیشتری نسبت به خروجی های خود داشته باشد ، اختلاف نیز به عنوان “هزینه معامله” به استخراج کننده می رسد. اتفاقاً این تنها سازوکاری است که به وسیله آن بیت کوین تعریف می شود.

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

بعد از اینکه مرحله (1) انجام شد ، بعد از چند دقیقه یک ماینری وارد آن معامله در یک بلوک ، به طور مثال بلوک شماره 270 می شود. بعد از حدود یک ساعت ، پنج بلوک دیگر بعد از آن بلوک به زنجیره اضافه می شوند ، با هر یک از این بلوک ها که به طور غیر مستقیم مربوط به معامله اصلی می شوند آن را “تأیید” می کنند. در این مرحله ، تاجر پرداخت را نهایی می کند و محصول را تحویل می دهد. از آنجا که در فرض ما این یک کالای دیجیتالی است ، تحویل فوری انجام می شود. اکنون ، مهاجم معامله دیگری ایجاد می کند که 100 بیت کوین را برای خود ارسال می کند. اگر مهاجم آن را به سادگی آزاد کند ، معامله پردازش نخواهد شد. ماینرها سعی می کنند تا معادله APPLY(S,TX) را اجرا کنند و متوجه می شوند TX یک UTXO مصرف می کند که دیگر در این “حالت”  وجود ندارد. بنابراین در عوض ، مهاجم یک “چنگال” از بلاکچین ایجاد می کند که شروع به استخراج نسخه دیگری از بلوک 270 می کند که به همان بلوک 269 به عنوان منشا اشاره دارد اما معامله جدید را به جای معامله قدیمی انجام می دهد. از آنجا که داده های بلوک متفاوت است ، این معامله مستلزم انجام دوباره اثبات کار است. علاوه بر این ، نسخه جدید مهاجم از بلوک 270 هش متفاوتی دارد ، بنابراین بلوک های اصلی 271 تا 275 به آن “اشاره” نمی کنند. بنابراین ، زنجیره اصلی و زنجیره جدید مهاجم کاملاً از هم جدا هستند. قاعده این است که در یک چنگال طولانی ترین بلاکچین درست تلقی می شود و بنابراین ماینرهای قانونی در زنجیره 275 کار می کنند در حالی که مهاجم به تنهایی روی زنجیره 270 کار می کند. برای اینکه مهاجم زنجیره بلوک خود را به طولانی ترین زمان انجام دهد ، باید قدرت محاسباتی بیشتری نسبت به بقیه شبکه ها داشته باشد تا بتواند این روند را جبران کند.

درخت مرکل

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

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

برنامه های جایگزین بلاکچین

ایده استفاده از مفهوم اصلی بلاکچین و به کار بردن آن در مفاهیم دیگر سابقه طولانی دارد. در سال 1998 ، نیک سابو مفهوم عنوان املاک امن با اختیار مالک را ارائه کرد ، سندی که توصیف می کند چگونه “پیشرفت های جدید در فناوری پایگاه داده تکثیر شده” امکان ایجاد یک سیستم مبتنی بر بلاکچین را برای ذخیره سازی دفتر ثبت اسناد را ایجاد میکند که مشخص می کند چه کسی صاحب چه زمینی است ، و چهارچوبی با جزیات مفصل شامل مفاهیمی مانند خانه داری ، “مالکیت بر اثر گذر زمان” و مالیات بر زمین در کشور گرجستان را خلق می کند. با این حال ، متأسفانه در آن زمان هیچ سیستم پایگاه داده تکثیر شده و موثری در دسترس نبود ، بنابراین این پروتکل هرگز در عمل اجرا نشد. به هر صورت ، پس از 2009 ، زمانی که اجماع غیر متمرکز بیت کوین ایجاد شد ، چندین برنامه جایگزین به سرعت در حال ظهور بودند.

Namecoin: در سال 2010 تولید شد ، بیشتر به عنوان پایگاه داده ثبت نام غیرمتمرکز شناخته می شود. در پروتکل های غیرمتمرکز مانند Tor ، Bitcoin و BitMessage ، باید روشی برای شناسایی حساب ها وجود داشته باشد تا افراد دیگر بتوانند با آنها ارتباط برقرار کنند ، اما در میان همه راه حل های موجود تنها معین کننده هویت موجود، یک هش شبه تصادفی است مانند: 1LW79wp5ZBqaHW1jL5TciBCrhQYtHagUWy

در نظر بگیرید ، یک نفر دوست دارد بتواند حسابی با نامی مانند “george” داشته باشد. در اینجا، مسئله این است که اگر یک نفر بتواند حسابی به نام “جورج” ایجاد کند آیا شخص دیگری می تواند از همان فرآیند برای ثبت “جورج” برای خود و جعل هویت وی استفاده کند. تنها راه حل یک الگوی اولویت در ثبت است ، جایی که اولین ثبت نام کننده موفق می شود و دومین کار با شکست مواجه می شود – راه حلی کاملا مناسب برای پروتکل اجماع بیت کوین. Namecoin  قدیمی ترین و موفق ترین اجرای سیستم ثبت نام با استفاده از چنین ایده ای است.

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

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

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

از طرفی دیگر ، روش مبتنی بر بیت کوین این نقص را دارد که ویژگی های ساده تأیید پرداخت بیت کوین را به ارث نمی برد. SPV برای بیت کوین کار می کند زیرا می تواند از عمق بلاکچین به عنوان پروکسی برای اعتبار سنجی استفاده کند.  از نقطه نظری دیگر اگر صاحبان یک معامله به اندازه کافی عقب بروند ، می توان گفت که آنها به طور قانونی بخشی از “حالت” بودند. علاوه بر این ، متا پروتکل های مبتنی بر بلاکچین نمی توانند بلاکچین را مجبور کنند که تراکنش هایی را که در متن پروتکل های خودشان معتبر نیستند ، در بر نگیرد. از این رو ، یک پیاده سازی کاملاً امن SPV متا پروتکل نیاز به اسکن عقبگرد تا ابتدای بلاکچین بیت کوین دارد تا مشخص شود بعضی معاملات خاص معتبر هستند یا خیر. در حال حاضر ، تمام تراکنش های “سبک” متا پروتکل های مبتنی بر بیت کوین برای فراهم کردن داده ها به یک سرور معتبر متکی هستند ، مسلماً نتیجه ای بسیار غیر بهینه حاصل می شود به خصوص هنگامی که یکی از اهداف اصلی ارز رمزنگاری شده از بین بردن نیاز به اعتماد است.

نسخه برداری(اسکریپت نویسی)

بدون شک ، پروتکل بیت کوین نسخه ضعیف مفهوم “قراردادهای هوشمند” را بهبود می بخشد. در بیت کوین می توان UTXO را نه تنها توسط یک کلید عمومی ، بلکه توسط یک نسخه یا اسکریپت پیچیده تر که با یک زبان برنامه نویسی با پایه ساده بیان می شود ، صاحب شد. در این الگو ، معامله ای که این UTXO را خرج می کند باید داده های متناسب با اسکریپت یا نسخه را ارائه دهد. در واقع ، حتی مکانیزم اصلی مالکیت کلید عمومی هم از طریق یک اسکریپت اجرایی می شود: اسکریپت یک امضای منحنی بیضوی را به عنوان ورودی می گیرد ، با قرار دادن امضا در برابر معامله و آدرس صاحب UTXO ،تأیید می کند و در صورت موفقیت آمیز بودن تأیید عدد 1 و در غیر این صورت 0 را نشان می دهد. اسکریپتهای پیچیده تر ، برای موارد مختلف وجود دارد. به عنوان مثال ، می توان رونوشت یا نسخه ای ساخت که برای تأیید اعتبار نیاز به امضای دو کلید خصوصی از سه کلید داده شده را دارد (“چند امضایی”) که می تواند یک تنظیمات مناسب برای حساب های شرکتی ، حساب های پس انداز امن و برخی از شرایط فروش تجاری باشد. همچنین می توان از اسکریپت ها برای پرداخت هزینه های گزاف به عنوان راه حلی برای مشکلات محاسباتی استفاده کرد. و حتی می توان اسکریپتی ساخت که چیزی مانند “این UTXO بیت کوین متعلق به شماست اگر بتوانید یک تاییدیه SPV مبنی براینکه  شما یک معامله Dogecoin از این پول را برای من ارسال کردید” ارائه دهد، که اساساً امکان مبادلات غیر متمرکز ارز رمزپایه را فراهم می کند.

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

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

نابینایی در ارزش گذاری – هیچ راهی برای یک رونوشت یا اسکریپت UTXO وجود ندارد که بتواند کنترل دقیق روی مقدار قابل برداشت داشته باشد. به عنوان مثال ، یک مورد استفاده قدرتمند از یک قرارداد اوراکل ، یک قرارداد مصون سازی شده است ، جایی که A و B  $ 1000 دلار به ارزش بیت کوین  قرار می دهند و پس از 30 روز اسکریپت  $ 1000 بیت کوین به A و بقیه را به B ارسال می کند. برای تعیین مقدار 1 بیت کوین  به دلار آمریکا به یک اوراکل احتیاج دارید ، اما حتی با این حال ، از نظر اعتماد و نیاز به زیرساخت نسبت به راه حل های کاملاً متمرکز که اکنون در دسترس هستند ، یک پیشرفت بسیار بزرگ است. با این وجود ، از آنجا که UTXO ها به صورت صفر یا صدی هستند، تنها راه دستیابی به این هدف از طریق یک هک بسیار ناشیانه و داشتن بسیاری از UTXO های مختلف است (به عنوان مثال یکUTXO  از k به توان 2 که برای هر k تا 30عدد) و همچنین داشتن انتخاب کننده O که انتخاب می کند کدام UTXO را برای A و کدام را برای B ارسال کند.

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

نابینایی در بلاکچین – UTXO نسبت به داده های بلاکچین مانند nonce ، زمان سنجی و هش بلوک قبلی نابینا است. این امر با محدود کردن زبان اسکریپت که از یک منبع بالقوه ارزشمند تصادفی استفاده می کند ، می تواند برنامه های کاربردی در قمار و چندین دسته دیگر را به شدت محدود کند.

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

اتریوم

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

فلسفه

طراحی موجود در اتریوم برای پیروی از اصول زیر در نظر گرفته شده است:

  1. سادگی: پروتکل اتریوم باید حتی در ازای ذخیره سازی داده ها یا زمان بری زیاد، حتی الامکان ساده باشد(نکته3). یک برنامه نویس عادی ​​باید در حالت ایده آل بتواند تمام مشخصات را پیگیری و پیاده سازی کند ، تا کاملاً به پتانسیل دموکراتیک سازی بی سابقه ای که ارز رمزنگاری شده به ارمغان می آورد و چشم انداز اتریوم به عنوان پروتکلی که برای همه در دسترس است ، پی ببرد(نکته4). هر گونه بهینه سازی که پیچیدگی را به همرا می آورد و سادگی را ازبین می برد نباید اضافه شود مگر اینکه این بهینه سازی سود بسیار چشمگیری را به همراه داشته باشد.
  2. جهانی شدن: یک قسمت اساسی از فلسفه طراحی اتریوم این است که اتریوم “ویژگی” ندارد(نکته5). در عوض ، اتریوم یک زبان برنامه نویسی داخلی کامل Turing را ارائه می دهد ، که یک برنامه نویس می تواند از آن برای ساخت هر نوع قرارداد هوشمند یا هر نوع معامله ای که می تواند از نظر ریاضی تعریف شود ، استفاده کند. آیا می خواهید مشتقات مالی خود را اختراع کنید؟ با اتریوم می توانید. می خواهید ارز خود را بسازید؟ آن را به عنوان قرارداد اتریوم تنظیم کنید. آیا می خواهید Daemon یا Skynet در مقیاس کامل راه اندازی کنید؟ ممکن است لازم باشد که چند هزار قرارداد بهم پیوسته داشته باشید و لازم باشد سخاوتمندانه آنها را گسترش دهید تا بتوانید این کار را انجام دهید ، اما هیچ چیز با استفاده از اتریوم مانع شما نمی شود.
  3. پیمانه ای(مدولار) بودن: بخش های پروتکل اتریوم باید به گونه ای طراحی شوند که تا حد امکان پیمانه ای و قابل تفکیک باشند. در طول توسعه ، هدف ما ایجاد برنامه ای است که اگر بخواهید یک پروتکل کوچک را در یک مکان ایجاد کنید ، پشته برنامه بدون هیچ گونه تغییری به کار خود ادامه می دهد. نوآوری هایی مانند ایتاش (به پیوست کاغذ زرد یا مقاله ویکی مراجعه کنید) ، درختان اصلاح شده پاتریشیا (کاغذ زرد ، ویکی) وRLP (ویکی) باید به عنوان کتابخانه های مجزا و با ویژگی کامل اجرا شوند. این امر بدین صورت است که حتی اگر از آنها در اتریوم استفاده شود و حتی اگر اتریوم به ویژگی های خاصی نیازی نداشته باشد ، چنین ویژگی هایی در پروتکل های دیگر نیز قابل استفاده هستند. توسعه اتریوم باید به شکل حداکثری انجام شود تا نه تنها به نفع خود آن بلکه به نفع کل اکوسیستم ارز رمزنگاری شده باشد.
  4. مهارت: جزئیات پروتکل اتریوم غیر قابل تغییر نیست. با این وجود که ما در مورد ایجاد اصلاحات در سازه های سطح بالا بسیار سختگیرانه عمل خواهیم کرد ، با استفاده از به عنوان مثال sharding roadmaps ، تقسیم بندی عملیات اجرایی و با در دسترس بودن داده هایی که در اجماع ذکر شده است. آزمایشات محاسباتی بعداً در فرآیند توسعه ممکن است ما را به این نتیجه برساند که برخی تغییرات خاص در معماری پروتکل یا در ماشین مجازی اتریوم (EVM)، مقیاس پذیری یا امنیت را به طور قابل توجهی بهبود می بخشد و اگر چنین فرصت هایی پیدا شود ، از آنها استفاده خواهیم کرد.
  5. عدم تبعیض و عدم سانسور: پروتکل نباید تلاش کند تا فعالیت دسته های خاصی را محدود یا از آنها جلوگیری کند. . تمام مکانیسم های نظارتی در این پروتکل باید به گونه ای طراحی شوند که مستقیماً آسیب ها را ترمیم کنند و سعی در مخالفت با برنامه های خاص نامطلوب نداشته باشند. یک برنامه نویس تا زمانی که مایل به ادامه پرداخت هزینه معامله در هر مرحله محاسباتی باشد حتی می تواند یک اسکریپت حلقه بی نهایت را بر پایه اتریوم اجرا کند.

 

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

در اتریوم ، نظام کلی از اشیایی تشکیل شده است که “حساب” نامیده می شوند ، و هر حساب یک آدرس 20 بایتی، انتقال حالت، انتقال مستقیم ارزش و اطلاعات بین حساب ها است. یک حساب اتریوم شامل چهار قسمت است:
  • nonce ، پیشخوانی است برای اطمینان از این که هر معامله فقط یکبار انجام می شود.
  • موجودی اتر فعلی حساب
  • کد قرارداد حساب (در صورت وجود)
  • فضای ذخیره سازی حساب (به طور پیش فرض خالی است)

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

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

پیام ها و معاملات

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

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

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

پیام ها

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

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

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

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

 

عملکرد انتقال حالت اتریوم


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

  1. بررسی کنید که آیا معامله به درستی شکل گرفته است (یعنی تعداد “ارزش” مناسبی دارد) ، امضا معتبر است و nonce با nonce ای که در حساب فرستنده است مطابقت دارد. در غیر این صورت خطا گزارش کنید.
  2. هزینه معامله را با عنوان STARTGAS * GASPRICE محاسبه کنید و آدرس ارسال را از روی امضا تعیین کنید. هزینه را از مانده حساب فرستنده کم کنید و nonce ارسال کننده را افزایش دهید. اگر میزان کافی برای هزینه وجود نداشته باشد ، خطا خواهد داد.
  3. برای شروع GAS = STARTGAS را در نظر گرفته و برای پرداخت بایت ها در معامله مقدار مشخصی گاز را در هر بایت خارج کنید.
  4. مقدار تراکنش را از حساب فرستنده به حساب گیرنده منتقل کنید. اگر حساب دریافت کننده ای هنوز وجود ندارد ، آن را ایجاد کنید. اگر حساب دریافت کننده یک قرارداد است ، کد قرارداد را تا پایان کار یا تمام شدن گاز اعمال کنید.
  5. اگر انتقال ارزش به دلیل نداشتن پول کافی فرستنده یا تمام شدن گاز اش انجام نشد ، تمام تغییرات وضعیت به جز پرداخت هزینه ها را برگردانید و هزینه ها را به حساب استخراج کننده اضافه کنید.
  6. در غیر این صورت ، هزینه تمام گازهای باقیمانده را به فرستنده پرداخت کنید و هزینه های پرداخت شده برای گاز هدر شده را برای استخراج کننده ارسال کنید.
به عنوان مثال ، فرض کنید که کد قرارداد به این صورت است:
if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)

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

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

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

توجه داشته باشید که پیام ها معادل معاملات کار می کنند اما با شرایط برگشت پذیر: اگر گاز ارسال پیام تمام شود ، اجرای آن پیام و سایر عملیات های ایجاد شده توسط آن اجرا ، بازگشت می خورد ، اما عملیات های مادر نیازی به بازگشت ندارند. این بدان معناست که اگر یک قرارداد با قرارداد دیگری ملاقات کند ، “امن” است ، کما اینکه اگر A با B با مقدارگاز G ملاقات کند ، در اینجا عملیات  Aبه طور تضمینی حداکثر مقدار G گاز از دست می دهد. در آخر ، در نظر داشته باشید که یک کد عملیاتی ایجاد شده وجود دارد که یک قرارداد را ایجاد می کند. مکانیک اجرای آن به طور کلی مشابه CALL است ، با این تفاوت که خروجی اجرا کد یک قرارداد تازه ایجاد شده را تعیین می کند.

 

اجرای کد

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

  • استک یا پشته ، یک محفظه last-in-first-out است که که می توان مقادیر را در آن قرار دار یا از آن خارج کرد.
  • حافظه، که یک ردیف از بایت ها است که میتوان آن را تا بینهایت گسترش داد.
  • ذخیره سازی طولانی مدت قرارداد ، که یک انبار سازی مهم و ارزشمند است. برخلاف پشته و حافظه که پس از پایان محاسبه مجدداً تنظیم می شوند ، فضای ذخیره سازی برای مدت طولانی می تواند حفظ شود.

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

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

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

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

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

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

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

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

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

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

سیستم های توکن بلاکچین دارای کاربردهای مختلفی هستند از ارزهای فرعی که نشان دهنده اموال هستند مانند دلار آمریکا یا طلا گرفته تا سهام شرکت ، توکن های به خصوص نمایانگر دارایی های هوشمند ، کوپن های غیر قابل جعل امن و حتی سیستم های توکن بدون هیچ ارتباطی با ارزش متعارف ، که به عنوان سیستم های نقطه ای برای انگیزه بخشی استفاده میشوند. پیاده سازی سیستم های Token به طرز شگفت آوری در اتریوم آسان است. نکته اصلی برای درک آن این است که یک ارز ، یا یک سیستم رمزگذاری ، اساساً یک پایگاه داده با یک عملکرد است: X واحد را از A کم کنید و X واحد را به B بدهید ، با این شرط که A حداقل X واحد قبل از معامله داشته باشد و  معامله توسط 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

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

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

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

با توجه به این اطلاعات حیاتی ، قرارداد هجینگ(ایمن شده) به شرح زیر است:
  1. صبر کنید تا طرف A 1000 اتر را وارد کند.
  2. صبر کنید تا طرفB 1000 اتر را وارد کند.
  3. دلار آمریکا به ارزش 1000 اتر را که با استعلام از قرارداد تغذیه داده محاسبه شده است ، در حافظه ذخیره کنید ، بگویید این مقدار $ x است.
  4. پس از 30 روز ، به A یا B اجازه دهید “قرارداد را مجددا” فعال کند تا به ارزش $ x اتر (محاسبه شده با استعلام از قرارداد تغذیه مجدد داده برای دریافت قیمت جدید) به A و بقیه به B ارسال شود.

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

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

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

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

def register(name, value):

if !self.storage[name]:

self.storage[name] = value

قرارداد بسیار ساده است. همه این یک پایگاه داده در داخل شبکه Ethereum است که می تواند به آن اضافه شود ، اما اصلاح یا حذف نشود. هر کسی می تواند نامی با مقداری ارزش را ثبت کند و سپس این ثبت نام برای همیشه ثابت می ماند. یک قرارداد با ثبت نام پیچیده تر دارای یک “فصل عملکرد” ​​است که به سایر قراردادها اجازه می دهد تا آن را استعلام کنند ، همچنین دارای مکانیزمی برای “مالک” (یعنی اولین ثبت کننده) یک نام برای تغییر داده ها یا انتقال مالکیت است. حتی می توان اعتبار و قابلیت اعتماد به وب (web of trust) را به آن اضافه کرد.

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

در طی چند سال گذشته ، تعداد زیادی از استارت آپ های محبوب ذخیره سازی پرونده های آنلاین ظهور کرده اند که برجسته ترین آنها Dropbox است ، که به کاربران اجازه می دهد یک نسخه پشتیبان تهیه شده از هارد دیسک خود را بارگذاری کنند و سرویس پشتیبان را ذخیره کرده و به کاربر در ازای دریافت هزینه ماهانه  اجازه دسترسی به آن را بدهد. با این حال ، در این جا بازار ذخیره فایل در بعضی مواقع نسبتاً ناکارآمد است. نگاهی گذرا به راه حلهای مختلف نشان می دهد که برای مثال در “دره ناآرام” (uncanny valley) 20-200 گیگابایتی که در آن نه سهمیه رایگان و نه تخفیف وجود دارد ، قیمت های ماهانه برای ذخیره سازی پرونده های اصلی به گونه ای است که شما از هزینه کل هارد دیسک خود در یک ماه هزینه بیشتری را پرداخت می کنید. قراردادهای اتریوم می توانند یک اکوسیستم ذخیره سازی فایل غیرمتمرکز را بهبود بخشند، جایی که کاربران شخصی می توانند با اجاره هارددیسک های خود مقادیر کمی پول بدست آورند و از فضای استفاده نشده برای کاهش هزینه های ذخیره سازی پرونده استفاده شود.

عامل کلیدی در چنین طرحی همان چیزی است که ما آن را “قرارداد غیرمتمرکز Dropbox” نامیده ایم. این قرارداد به روش زیر عمل می کند. در ابتدا ، یک نفر داده های مورد نظر را میان بلوک ها تقسیم کرده و برای حفظ محرمانه بودن هر بلوک را رمزگذاری کرده و از آن یک درخت مرکل می سازد. سپس یك نفر با این قاعده كه به ازای هر n بلوك ، قرارداد یك شاخص تصادفی در درخت Merkle را انتخاب می كند (با استفاده از هش بلوك قبلی و قابل دسترسی از كد قرارداد ، به عنوان منبع تصادفی) قرارداد می بندد و X اتر را در آن شاخص خاص در درخت به اولین نهادی که توانایی انجام یک معامله را با اثبات تأیید پرداخت ساده مانند مالکیت بلوک را داشته باشد، ارائه می دهد. هنگامی که یک کاربر می خواهد پرونده خود را بارگیری مجدد کند ، می تواند از یک پروتکل کانال پرداخت خرد (به عنوان مثال پرداخت 1 szabo به ازای هر 32 کیلوبایت) برای بازیابی پرونده اش استفاده کند. مرقون به صرفه ترین روش این است که پرداخت کننده معامله را تا پایان صادر نکند و در عوض می تواند بعد از هر 32 کیلوبایت معامله پردرآمد تر با همان nonce را جایگزین معامله کند.

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

 

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

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

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

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

در این قرارداد بندهایی برای هر یک از این موارد در نظر گرفته شده است. در اینجا یک سابقه از تمام تغییرات ذخیره سازی باز ، همراه با لیستی از کسانی که به آنها رأی داده اند ، نگهداری می شود. همچنین لیستی از همه اعضا خواهد داشت. وقتی هر تغییر ذخیره به دو سوم اعضا که به آن رأی می دهند برسد ، یک معامله نهایی می تواند تغییر را اجرا کند. یک اسکلت پیچیده تر نیز می تواند قابلیت رأی گیری داخلی برای ویژگی هایی مانند ارسال یک معامله ، افزودن اعضا و حذف اعضا را داشته باشد ، و حتی ممکن است برای نمایندگی رای گیری به سبک دموکراسی مایع (به عنوان مثال هر کسی می تواند کسی را تعیین کند که به آنها رأی دهد و این واگذاری رای قابل انتقال است بنابراین اگر A به B و B به C اختصاص دهد ، C رای A را تعیین می کند) شرایط را فراهم کند. این طراحی به DAO این امکان را می دهد که به عنوان یک جامعه غیرمتمرکز رشد ارگانیک داشته باشد ، به افراد اجازه می دهد تا در نهایت وظیفه فیلتر کردن عضو را به متخصصان واگذار کنند ، اگرچه بر خلاف “سیستم فعلی” متخصصان به راحتی می توانند در طول زمان ظاهر و از رده خارج شوند همانطور که اعضای شرکت های خصوصی همکاری خود را تغییر می دهند.

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

برنامه های بیشتر

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

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

بیمه محصول

  1. بیمه محصول- به راحتی می توان به جای هر شاخص قیمت با استفاده از منبع اطلاعات آب و هوا ، یک قرارداد مشتقه مالی منعقد کرد. اگر یک کشاورز در آیووا مشتقی خریداری کند که بر اساس میزان بارندگی در آیووا هزینه معکوس پرداخت کند ، در صورت خشکسالی ، کشاورز به طور خودکار پول دریافت می کند و اگر باران کافی باشد ، کشاورز خوشحال خواهد بود زیرا محصولاتش محصول خوبی دارند. این مورد را می توان به طور کلی به بیمه بلایای طبیعی تعمیم داد.
  2. یک منبع تغذیه غیرمتمرکز. برای قراردادهای مالی متفاوت ، ممکن است غیرمتمرکز کردن منبع تغذیه از طریق پروتکلی به نام SchellingCoin امکان پذیر باشد. SchellingCoin اساساً به شرح زیر عمل می کند: تعداد N شرکت کننده همه مقدار یک داده تحویل شده را در سیستم قرار می دهند (به عنوان مثال قیمت ETH / USD) ، مقادیر مرتب می شوند و بر حسب درصد هر کس بین 25ام و 75ام باشد یک رمز به عنوان پاداش دریافت می کند. همه انگیزه ارائه پاسخی را دارند که بقیه ارائه خواهند داد و تنها ارزشی که تعداد زیادی از بازیکنان می توانند در مورد آن توافق کنند ، پیش فرض حقیقی است. این روش یک پروتکل غیرمتمرکز ایجاد می کند که از لحاظ نظری می تواند هر تعداد “ارزش” را ارائه دهد ، از جمله قیمت ETH / USD ، درجه حرارت در برلین یا حتی نتیجه یک محاسبه سخت خاص.
  3. محافظ چند علامت هوشمند – بیت کوین قراردادهای معاملاتی چند امضایی را مجاز می داند که به عنوان مثال ، از هر پنج کلید سه کلید می تواند پول را خرج کند. اتریوم امکان دانه بندی بیشتر را فراهم می کند. به عنوان مثال ، از هر پنج نفر چهار نفر می توانند همه چیز را خرج کنند ، از هر پنج نفر سه نفر می توانند تا 10٪ در روز خرج کنند و از هر پنج نفر دو نفر می توانند 0.5٪ در روز خرج کنند. علاوه بر این ، خاصیت چند امضایی اتریوم ناهمزمان است – دو فرد می توانند امضاهای خود را در زمان های مختلف در بلاکچین ثبت کنند و آخرین امضا به طور خودکار معامله را ارسال می کند.
  4. پردازش ابری. از فناوری EVM همچنین می توان برای ایجاد یک محیط محاسباتی قابل تأیید استفاده کرد که به کاربران اجازه می دهد تا از دیگران بخواهند محاسبات را انجام دهند و سپس به صورت اختیاری خواستار اثبات صحت انجام محاسبات در برخی از ایست های بازرسی تصادفی شوند. این کار امکان ایجاد یک بازار رایانه ای ابری را فراهم می کند که در آن هر کاربر می تواند با دسک تاپ ، لپ تاپ یا سرور تخصصی خود شرکت کند و برای اطمینان از قابل اعتماد بودن سیستم می توان از بررسی نقطه ای همراه با سپرده های امنیتی استفاده کرد (به عنوان مثال گره ها نمی توانند در سود دهی تقلب کنند) . اگرچه چنین سیستمی ممکن است برای همه کارها مناسب نباشد. کارهایی که به سطح بالایی از ارتباط بین فرآیند نیاز دارند ، به عنوان مثال ، نمی توانند به راحتی در ابر بزرگی از گره ها این کار را انجام دهند. با این وجود کارهای دیگر، بسیار راحت تر قابل موازی سازی است. پروژه هایی مانند SETI @ home ، folding @ home و الگوریتم های ژنتیک به راحتی بر پایه چنین بستری قابل اجرا هستند.
  5. قمار دو به دو(peer to peer) هر تعداد پروتکل قمار دو به دو ، مانند تاس سایبری(cyberdice)Frank Stajano و Richard Clayton ، را می توان در بلاک چین اتریوم پیاده سازی کرد. ساده ترین پروتکل قمار در واقع یک قرارداد برای تفاوت در هش بلوک بعدی است و می توان از آنجا پروتکل های پیشرفته تری ایجاد کرد و خدمات قمار را با هزینه های نزدیک به صفر ایجاد کرد که توانایی تقلب ندارند.
  6. بازارهای پیش بینی- با ارائه یک پیش گویی یا SchellingCoin ، بازارهای پیش بینی نیز به راحتی قابل اجرا هستند و بازارهای پیش بینی همراه با SchellingCoin ممکن است ثابت شود که اولین کاربرد اصلی futarchy به عنوان یک پروتکل نظارت بر سازمان های غیرمتمرکز است.
  7. بازارهای غیر متمرکز زنجیره ای که از سیستم هویت و شهرت به عنوان پایگاه استفاده می کنند.

 

 

تنوع و نگرانی ها

به کار گیری GHOST اصلاح شده

پروتکل ”GHOST” (Greedy Heavyest Obsored Subtree) یک نوآوری است که برای اولین بار توسط Yonatan Sompolinsky و Aviv Zohar در دسامبر 2013 ارائه شد. نیروی محرکه GHOST بلاکچین هایی است که زمان تأیید سریع دارند و در حال حاضر از کمبود امنیت به دلیل فرسودگی زیاد رنج می برند زیرا انتشار بلوک ها از طریق شبکه زمان مشخصی را می طلبد ، اگر ماینر A یک بلاک را استخراج کند و سپس ماینر B قبل از انتشار بلوک ماینر A به B ، یک بلاک دیگر را استخراج کند ، بلوک ماینر B در نهایت هدر می رود و به امنیت شبکه کمک نمی کند. علاوه بر این ، یک مسئله سنترالیزاسیون وجود دارد: اگر استخراج کننده A استخر استخراج با 30٪ قدرت هش و B دارای 10٪ قدرت هش باشد ، خطر تولید بلوک فرسوده توسط A  70٪ ازمواقع است( از آنجایی که در 30٪ باقی مواقع A آخرین بلوک را ساخته است بنابراین اطلاعات استخراج را به سرعت دریافت می کند) در حالی که B در 90٪ از مواقع بلوک فرسوده تولید می کند. بنابراین ، اگر فاصله بلوک به اندازه کافی کوتاه باشد تا نرخ stale (فرسورگی) بالا باشد ، A صرفاً به دلیل اندازه آن کارآمدتر خواهد بود. با ترکیب این دو ، بلاکچین هایی که به سرعت بلوک تولید می کنند به احتمال زیاد منجر به این می شوند که یک استخر استخراج دارای درصد کافی از قدرت هش شبکه داشته باشیم  تا بتواند به طور عملی بر روند استخراج کنترل داشته باشد.

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

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

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

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

هزینه ها

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

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

  1. یک معامله منجر به عملیات k می شود و در آن جایی که R توسط فرستنده تعیین می شود و k و R برای استخراج کننده قابل مشاهده است ، پاداش kR را به هر استخراج کننده ای که آن را انجام دهد پیشنهاد می دهد.
  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 را افزایش می دهد. بنابراین ، این دو حداقل تا حدی یکدیگر را لغو می کنند. چگونه؟ شماره 3 و 4 مسئله اصلی هستند؛ برای حل آنها ما به راحتی یک cap شناور ایجاد می کنیم: هیچ بلوکی نمی تواند بیش از 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 برای انجام پرش مشروط ، جمله هایی مانند while x < 27: x = x * 2  را می دهد. دوم ، قراردادها می توانند با سایر قراردادها ارتباط برقرار کنند که به طور بالقوه امکان حلقه زدن در حین بازگشت را فراهم می کند. این کار به طور طبیعی به یک مشکل منجر می شود: آیا کاربران مخرب اساساً می توانند ماینرها و گره های کامل را وادار به ورود به یک حلقه بی نهایت کنند؟ این مسئله به دلیل مشکلی در علوم کامپیوتر به نام مشکل توقف (halting) بوجود می آید: به طور کلی راهی برای تشخیص اینکه آیا برنامه معینی متوقف خواهد شد یا خیر ، وجود ندارد.

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

  • یک مهاجم قراردادی ایجاد می کند که یک حلقه بی نهایت را اجرا می کند ، و سپس یک معامله که حلقه را برای ماینر فعال می کند می فرستد. ماینر معامله را پردازش می کند ، حلقه بی نهایت را اجرا می کند و منتظر می ماند تا گاز آن تمام شود. حتی اگر گاز اجرای آن تمام شود و در نیمه راه متوقف شود ، معامله همچنان معتبر است و ماینر برای هر مرحله محاسبات هنوز هزینه را از مهاجم دریافت می کند.
  • یک مهاجم یک حلقه نامحدود بسیار طولانی ایجاد می کند با این انگیزه که ماینر را مجبور کند برای مدت طولانی محاسبات را ادامه دهد تا زمانی که محاسبه به پایان برسد ، چند بلوک دیگر بیرون می آیند و برای مطالبه هزینه امکان انجام معامله برای ماینر وجود ندارد. با این حال ، مهاجم ملزم به ارائه مقداری برای STARTGAS می شود که تعداد مراحل محاسباتی را که می تواند انجام دهد ، محدود می کند ، بنابراین ماینر پیش از موعد می داند که محاسبه تعداد مراحل بیش از حد زیادی را انجام خواهد داد.
  • یک مهاجم قراردادی را با کدهای نوعی شکل مانند send(A,contract.storage[A]) می بیند. 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 به توان 50 مرحله محاسباتی را طی می کند. ماینر ها می توانند با حفظ یک ارزش در کنار هر قرارداد با تعیین حداکثر تعداد مراحل محاسباتی که می تواند برداشته شود و محاسبه این مورد برای قراردادهایی که سایر قراردادها را به طور متناوب انجام می دهند ، زودتر از موعد چنین بمب های منطقی (logic bombs)را تشخیص دهند ، اما این امر مستلزم ممنوع کردن قراردادهایی است که سایر قراردادها را ایجاد می کند (از آنجا که ایجاد و اجرای هر 26 قرارداد فوق می تواند به راحتی در یک قرارداد منعقد شود). نکته مشکل ساز دیگر این است که قسمت آدرس پیام یک متغیر است ، بنابراین به طور کلی حتی ممکن نیست بتوان گفت که قرارداد معین قبل از موعد با کدام یک از قراردادهای دیگر مرتبط می شود. از این رو ، در مجموع ، ما یک نتیجه شگفت آور داریم: مدیریت کامل بودن تورینگ به طرز شگفت انگیزی آسان است ، و مدیریت عدم کامل بودن تورینگ به همان اندازه که مورد قبل آسان بود، دشوار است مگر اینکه دقیقاً همان کنترل ها اعمال شود – اما در این مورد چرا اجازه ندهیم پروتکل، تورینگ کامل باشد؟

ارز و صدور

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

  • 1: wei
  • 1012: szabo
  • 1015: finney
  • 1018: ether

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

مدل صدور به شرح زیر است:
  • Ether در یک بازار فروش ارز با قیمت 1000-2000 اتر به ازای هر بیت کوین عرضه خواهد شد ، مکانیزمی که برای تأمین بودجه سازمان اتریوم و پرداخت هزینه های توسعه طراحی شده است و با موفقیت توسط سیستم عامل های دیگر مانند Mastercoin و NXT استفاده شده است. خریداران قبلی از تخفیف های بیشتری بهره مند می شوند. بیت کوین دریافت شده از فروش به طور کامل برای پرداخت حقوق و دستمزد به توسعه دهندگان و سرمایه گذاری در پروژه های مختلف انتفاعی و غیر انتفاعی در اکوسیستم اتریوم و ارزهای رمزپایه استفاده می شود.
  • 099x کل مبلغ فروخته شده (60102216 ETH) به سازمان برای جبران خسارت به مشارکت کنندگان اولیه و پرداخت هزینه های مرتبط با ETH قبل از بلوک ابتدایی اختصاص می یابد.
  • 099x کل مبلغ فروخته شده به عنوان ذخیره بلند مدت حفظ خواهد شد.
  • 26x کل مبلغ فروخته شده برای همیشه بعد از آن زمان به ماینر ها هر ساله اختصاص می یابد.
گروه در زمان راه اندازی، پس از 1 سال و پس از 5 سال

واحدهای ارزی 1.198X 1.458X 2.498X خریداران 83.5٪ 68.6٪ 40.0٪ ذخیره پیش فروش 8.26٪ 6.79٪ 3.96٪ ذخیره استفاده شده پس از فروش 8.26٪ 6.79٪ 3.96٪ ماینر ها 0٪ 17.8٪ 52.0٪

تأمین یا عرضه دراز مدت نرخ رشد (درصد)

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

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

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

توجه داشته باشید که در آینده ، احتمالاً اتریوم به یک مدل اثبات سهام (proof of stake) برای امنیت تبدیل می شود که میزان صدور را به حدی بین صفر تا0.05X  در سال کاهش می دهد. درصورتی که سازمان اتریوم بودجه خود را از دست بدهد یا به هر دلیل دیگری از بین برود ، ما یک “قرارداد اجتماعی” را باز می گذاریم که در آن هر کسی حق ایجاد نسخه پیشنهادی اتریوم بعدی را دارد ، تنها شرط آن این است که مقدار اتر باید حداکثر برابر با  60102216 * (1.198 + 0.26 * n) باشد که n تعداد سالهای بعد از بلوک ابتدایی است. خالقین آزاد هستند که به فروش گسترده بپردازند و یا در غیر این صورت مقداری یا همه تفاوت بین پیشروی عرضه مبتنی بر PoS و حداکثر میزان پیشروی عرضه مجاز را برای پیشرفت توسعه معین کنند. ارتقا نامزدهایی که مطابق با قرارداد اجتماعی عمل نمی کنند ، ممکن است به درستی در نسخه های سازگار جای گیرد.

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

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

هدف فعلی در اتریوم استفاده از یک الگوریتم استخراج است که در آن استخراج کنندگان باید داده های تصادفی را از “حالت” بیرون بکشند که در آن برخی از معاملات به طور تصادفی انتخاب شده را از آخرین بلوک N بلاکچین محاسبه کرده و هش نتیجه را بازمی گردانند. این روش دو مزیت مهم دارد. اول ، قراردادهای اتریوم می توانند شامل هر نوع محاسبه ای باشند ، بنابراین یک ASIC  اتریوم اساساً یک ASIC برای محاسبه عمومی است (یعنی پردازنده بهتر). دوم ، استخراج نیاز به دسترسی به کل بلاکچین دارد ، استخراج کنندگان مجبور می شوند کل بلاکچین را ذخیره کنند و حداقل توانایی تأیید هر معامله ای را باید داشته باشند. این امر نیاز به استخرهای استخراج متمرکز را برطرف می کند. اگرچه استخرهای استخراج هنوز هم می توانند نقش قانونی تساوی توزیع پاداش را داشته باشند این عملکرد را می توان به طور یکسان توسط استخرهای نظیر به نظیر (peer to peer pools)و بدون کنترل مرکزی انجام داد.

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

مقیاس پذیری   

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

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

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

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

نتیجه گیری

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

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

 

 

نکات و مطالعات بیشتر

نکات
  1. یک شخص کارکشته ممکن است متوجه شود که در واقع یک آدرس بیت کوین هش کلید عمومی منحنی بیضوی است و نه کلید عمومی. با این حال ، اگر که از هش pubkey به عنوان یک کلید عمومی استفاده شود در واقع یک واژه گزینی رمزنگاری کاملاً قانونی است. دلیل این امر این است که رمزنگاری بیت کوین را می توان یک الگوریتم امضای دیجیتال سفارشی دانست ، جایی که کلید عمومی متشکل از هش ECC pubkey است ، امضا شامل ECC pubkey است که با امضای ECC تلفیق شده است و الگوریتم تأیید شامل بررسی ECC است. pubkey در امضا علیه ECC هاب pubkey به عنوان یک کلید عمومی ارائه شده و سپس تأیید امضای ECC علیه pubkey ECC.
  2. از نظر فنی ، میانه 11 بلوک قبلی است.
  3. پروتکل اتریوم باید به همان سادگی باشد که در عمل هست، اما ممکن است لازم باشد پیچیدگی بسیار بالا داشته باشد، به عنوان مثال مقیاس سازی ، داخلی سازی هزینه های ذخیره سازی ، پهنای باند و ورودی و خروجی ، برای امنیت ، حفظ حریم خصوصی ، شفافیت و غیره. در مواردی که پیچیدگی لازم است ، اسناد باید تا حد ممکن واضح ، مختصر و به روز باشد ، تا کسی که کاملاً در دانشگاه اتریوم را تحصیل نکرده است ، بتواند آن را بیاموزد و متخصص شود.
  4. مقاله زرد را برای ماشین مجازی اتریوم ببینید (که به عنوان مشخصات و مرجع ساخت یک مشتری اتریوم از ابتدا مفید است) ، در حالی که همچنین در ویکی اتریوم موضوعات زیادی وجود دارد ، مانند توسعه خرد کردن ، توسعه هسته ، توسعه dapp ، تحقیق ، تحقیق و توسعه کاسپر و پروتکل های شبکه. برای تحقیق و اجرای احتمالی آینده https://ethresear.ch/ وجود دارد.
  5. روش دیگر بیان این امر انتزاع است. آخرین نقشه راه برای اجرای انتزاعی در نظر گرفته شده است ، به موتورهای اجرایی این امکان را می دهد که لزوماً از یک مشخصات متداول پیروی نکنند ، اما به عنوان مثال می تواند برای یک برنامه خاص و همچنین خرده ریز طراحی شود. (این ناهمگنی موتورهای اعدام به صراحت در نقشه راه بیان نشده است. همچنین پارگی ناهمگنی وجود دارد که ولاد زامفیر آن را مفهوم سازی کرد.)
  6. از نظر داخلی ، 2 و “CHARLIE” هر دو عدد هستند ، که اعداد می توانند حداقل 0 و حداکثر 2 به توان 256 منهای 1 باشند.

 

 

 

 

 

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

  1. Intrinsic value
  2. Smart property
  3. Smart contracts
  4. B-money
  5. Reusable proofs of work
  6. Secure property titles with owner authority
  7. Bitcoin whitepaper
  8. Namecoin
  9. Zooko's triangle
  10. Colored coins whitepaper
  11. Mastercoin whitepaper
  12. Decentralized autonomous corporations, Bitcoin Magazine
  13. Simplified payment verification
  14. Merkle trees
  15. Patricia trees
  16. GHOST
  17. StorJ and Autonomous Agents, Jeff Garzik
  18. Mike Hearn on Smart Property at Turing Festival
  19. Ethereum RLP
  20. Ethereum Merkle Patricia trees

Peter Todd on Merkle sum trees

مطالب پیشنهادی

لینک مطلب:

کپی شد

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.

این قسمت نباید خالی باشد
این قسمت نباید خالی باشد
لطفاً یک نشانی ایمیل معتبر بنویسید.
شما برای ادامه باید با شرایط موافقت کنید

مطالب پر بازدید

.

فهرست