بنیاد اتریوم از همان روز های اولیه ی پروژه، یعنی در حدود سال های ۲۰۱۳ و اوایل ۲۰۱۴، دنیای قیمت بیت کوین
ماشین مجازی اتریوم (EVM) به نود های اتریوم اجازه می دهد تا اطلاعات را در قبال دستمزد، ذخیره و پردازش کنند. این تراکنش ها در راستای پاسخ به رویداد های دنیای واقعی است؛ همچنین فرصت های جدید بسیاری برای حمایت از برنامه های زنجیره ای، که تا قبل از این هیچوقت برای توسعه دهندگان و کاربران دنیای واقعی در دسترس نبودند، به ارمغان می آورد.
Mihai Alisie از بنیان گذاران اتریوم، در مورد قرارداد هوشمند اتریوم اینگونه توضیح می دهد:
«قرارداد های هوشمند راهی برای مردمِ سراسر دنیا است تا کار های خود را حتی زمانی که یک زبان یا یک ارز مشترک نداشته باشند انجام دهند.»
بنابراین با این چشم انداز و این ایده که می توانیم قوانین یک قرارداد تجاری را به وسیله یک زبان ماشین ساده تعریف کنیم تا مردم را در کنار یکدیگر جمع کرده و به آن ها این اجازه را بدهیم تا کسب و کار ها را به گونه ای قابل اطمینان، امن، به روز و خودکار هدایت کنند، شروع می کنیم.
زبان برنامه نویسی solidity یک ابزار است که از آن برای تولید کد سطح ماشین استفاده می کنیم تا بتوانیم بر روی EVM اجرا نماییم. solidity یک زبان برنامه نویسی با یک کامپایلر است که کد سطح بالا و خوانا برای انسان را برداشته و آن را به دستور های ساده مانند «put data into a register»، «add data from two registers»، «jump back to instruction at memory point xxxxx» تبدیل می کند که اساس برنامه اجرایی هر ریز پردازنده را تشکیل می دهند.
بنابراین زبان برنامه نویسی solidity تنها یکی از چندین زبانی است که می توانند به بایت کد (bytecode) EVM کامپایل شوند؛ زبان برنامه نویسی دیگری که کار مشابهی انجام می دهد Serpent نام دارد. هر زبان برنامه نویسی ممکن است تعدادی ابزار کامپایلر داشته باشد اما همه ی آن ها یک کار، یعنی همان تولید بایت کد EVM در سطح ماشین برای اجرا شدن در نود های اتریوم، که سرانجام به پرداخت می انجامد را انجام می دهند.
چگونه زبان برنامه نویسی Solidity را بیاموزیم؟
زبان برنامه نویسی Solidity به خودی خود زبان ساده ای است. در حقیقت، این زبان سینتکسی بسیار مشابه به ECMAScript یا همان جاوا اسکریپت دارد. نکات کلیدی ای برای مرور سند Ethereum Design Rationale وجود دارد؛ از جمله اینکه با یک مدل stack-and-memory با حافظه ی ۳۲ بایت کار می کنیم. EVM اجازه دسترسی به برنامه «stack» را که شبیه به یک فضای رجیستر است و در آن می توانیم آدرس های حافظه را به یکدیگر بچسبانیم تا برنامه را وادار به تکرار حلقه و یا پرش (برای کنترل مستمر برنامه) بکنیم، را می دهد. همچنین، دارای یک «memory» موقت و قابل گسترش، یک حافظه «storage» دائمی که در واقع درون بلاک چین دائمی نوشته شده است. از همه مهم تر، EVM نیاز به قطعیت کامل در قرارداد های هوشمند دارد.
این نیاز به قطعیت، همان دلیلی است که شما تابع «random()» را در زبان برنامه نویسی Solidity مشاهده نمی کنید. وقتی که یک بلاک اتریوم استخراج می شود، قرارداد هوشمند اجرا شده و توابع درون بلاک فراخوانی می شوند (به این معنی که به آخرین بلوک متصل می شود) و در نودی که بلوک را استخراج می کند اجرا می شود. سپس بلوک جدید در میان دیگر نود ها نیز منتشر می شود و هر نود به صورت مستقل بلوک را تایید می کند. این تایید شامل انجام همان تغییرات در کپی هر نود از بلاک چین است. اینجا همان جایی است که اگر قرارداد هوشمند به طور غیر قطعی عمل کند با شکست مواجه می شود. اگر بقیه ی نود ها نتوانند به توافقی درباره ی وضعیت بلاک چین بعد از بلوک جدید و اجرای قرارداد آن برسند، در این صورت شبکه به معنای واقعی از کار می افتد.
به همین دلیل، قرارداد های هوشمند اتریوم (و به طور کلی قرارداد های هوشمند در هر سیستم بلاک چینی) باید قطعیت داشته باشند. در این صورت، نود های شبکه همیشه می تواند بلوک های جدیدی که برای تایید می آیند را ارزیابی کنند و برای حفظ آن ها توافق نمایند تا از این طریق بلاک چین تداوم یابد.
محدودیت دیگری که در قرارداد های هوشمند EVM با آن مواجه می شوید، ناتوانی در دسترسی به داده های خارج از «memory»، «storage» (ما نمی خواهیم که قرارداد هوشمند این قابلیت را داشته باشد که بتواند hard-drive نودی که روی آن اجرا می شود را بخواند یا پاک کند)، و درمورد ناتوانی در پرس و جو از منابع خارج، مشابه JQuery است. همچنین، توانایی دسترسی به بسیاری از توابع کتابخانه ای مانند دستور های JSON را نداریم؛ در حقیقت برای انجام این فرایند ها یا ذخیره ی مقدار زیادی داده در خود بلاک چین اتریوم، هزینه ی زیادی لازم است.
وقتی شما یک قرارداد هوشمند که شامل تغییر وضعیت یا محاسبات (هر عملی غیر از صرفا خواندن از storage) می شود را فراخوانی می کنید، شما یک «gas cost» برای کار هایی که توسط قرارداد هوشمند انجام می شود متحمل می شوید. این gas cost مرتبط با مقدار کار محاسباتی لازم برای اجرای تابع شماست. این نوعی از سیستم «micropayment for microcomputing» است، جایی که می توانید انتظار داشته باشید که همیشه مقدار gas ثابتی برای انجام محاسبات معین، بپردازید.
قیمت gas به طور کلی ثابت است، به این معنی که وقتی اتریوم در بازار جهانی با افزایش قیمت مواجه می شود قیمت gas در مقابل اتریوم کاهش می یابد. بنابراین، وقتی شما توابع یک قرارداد هوشمند را فراخوانی می کنید، می توانید تخمینی از مقدار gas که باید قبل از آن بپردازید را به دست آورید. همچنین شما باید قیمتی که تمایل به پرداخت آن دارید را نیز مشخص کنید (که واحد آن ether بر gas است). سپس، نود های استخراج کننده می توانند تصمیم بگیرند که آیا این نرخ برای قرار دادن تابع فراخوانی شده قرارداد هوشمند شما، در بلوک بعدی خودشان کافی هست یا نه.
قرارداد های هوشمند، آدرس متعلق به خودشان را دارند که می توانند با آن Ether دریافت و ارسال کنند. مسیر فراخوانی توابع در قرارداد های هوشمند قابل ردیابی است، بنابراین می توان فهمید که تابع توسط «مالک» یا «admin» فراخوانی شده و نیز، بر اساس توابع پیش فرض عمل می کنند. آن ها این قابلیت را دارند که داده ها را از روی بلاک چین اتریوم بخوانند و به اطلاعات بلوک های قدیمی تر دسترسی داشته باشند. اما آیا قرارداد های هوشمند در دنیای کوچک و با قطعیت خودشان «حبس» شده اند تا فقط از داده های ذخیره شده در خود بلاک چین اتریوم آگاهی داشته باشند؟
به هیچ وجه! در اینجا مفهوم «oracles» وارد می شود. ما می توانیم یک oracle را فراخوانی کنیم که چیز های قابل اطمینانی در مورد دنیای بیرون به ما خواهد گفت و اطلاعات را داخل قرارداد هوشمند اعمال خواهد کرد. نکته ی کلیدی اینجاست که حتی خودِ رویداد های درون دنیای واقعی نیز قطعی نیستند. Oracle همیشه می تواند پاسخ صادقانه ای به درخواست نود برای پاسخ در مورد آنچه قطعا اتفاق افتاده بدهد. لذا نود ها همچنان می توانند به یک توافق برسند.
در واقع، آنچه اتفاق می افتد این است که کسی بگوید چه دیتایی نیاز دارد و سرویس مورد اعتمادش یک ID شناسایی (که در اینجا هش اطلاعات است) و یک کلید برای امضای نتایج فراهم کند، سپس کسی یک تراکنش به قرارداد بفرستد و در نهایت در انتظار نتایج بمانیم. هنگامی که نتایج مشخص شدند، سرویس مورد اعتماد آن را با کلید خود امضا می کند. کسی تراکنش دیگری که حاوی داده های امضا شده به قرارداد است، ارسال می کند و قرارداد، کاری را انجام می دهد که قرار است اتفاق بیفتد.
این کار را می توان به صورت زنجیر وار یا غیر زنجیر وار انجام داد. به طور معمول، چنین فرایندی بخشی از DApp است. آنها فرایند را غیر زنجیر وار انجام می‌دهند؛ به این معنی که فقط داده های امضا شده و یک کلید ارائه می دهند. کاربران این اطلاعات را از سایت می گیرند و به قرارداد هوشمند خودشان می فرستند. Oraclize این فرایند را زنجیر وار انجام می دهد، بدین ترتیب که قرارداد شما یک تقاضا به قرارداد آن ها ارسال می کند، قرارداد آنها این درخواست را بخش رویداد ها ثبت کرده و یک شناسه برای شما می فرستد. آنها فرایندی برای مشاهده رویداد ها دارند و وقتی دیتا آماده شد، آن را به صورت امضا شده برای شما می فرستند تا بتوان فرستنده قرارداد را ارزیابی کرد (در واقع، راه دیگری برای ارزیابی شخص امضا کننده اطلاعات است)؛ و در نهایت، آنچه که باید به اجرا درآید اجرا می شود.
بنابراین، oracle در تئوری قابل اطمینان عمل می کند: یک oracle مقداری داده دارد (منبعی از نوسان قیمت در جهان واقعی) و آن داده ها را درون «storage» در یک قرارداد هوشمند Oracle ساده ثبت می کند، چیزی شبیه به این:
function storeTickerData(bytes8 symbol, uint open, uint high, uint low, uint close)
onlyOracle
returns(bool success)
{
# store ticker data on-chain
tickerData[symbol][block.number] = [open,high,low,close]
# tickerData is a map of maps, string => uint => array[uint,uint,uint,uint]
return true;
}
شرکت هایی وجود دارند که در قابل اطمینان بودن Oracle ها و طراحی سیستم هایی برای متمایز ساختن خودشان برای قابل اطمینان بودن از طریق datafeed، تخصص دارند. اگر نگاهی به Oraclize documentation داشته باشیم با این متن جالب مواجه می شویم:
«در حقیقت، هدف این نیست که توسعه دهندگان قرارداد های هوشمند را مجبور به داشتن Oraclize قابل اعتماد داده هایی که به آن نیاز دارند بکنیم. بدون هیچگونه حمایت و پشتیبانی هم oraclize می تواند به راحتی داده ها را دستکاری کند. به این دلیل، به منظور تکمیل این کار پیچیده، oraclize اطلاعات درخواست شده را با روش «اثبات صحت» باز می گرداند. برای مثال، داده هایی توسط ارائه دهنده دیتا ارسال می شوند که به وضوح توسط قرارداد هوشمند مورد نیاز است.»
بنابراین باید «اثبات صحت» را با جزئیات بیشتر بررسی کنید که در این مجال نمی‌گنجد، اما ایده این است که حتی وقتی خوره های (nerds) جدید اتریوم در آینده نه چندان دور شروع به کار کنند، نود های اتریوم شان به گردش درآید و بلاک چین آن ها با شبکه همگام شود. همه ی داده هایی که نیاز دارند، همه ی قرارداد های هوشمندِ «oracle-dependent» زنجیر وار، قابل اطمینان و به طور دائمی برای دانلود در دسترس آن هاست. بحث درمورد کسانی که «gas» برای oracle پرداخت می کنند تا همه ی این داده نویسی ها را درباره ی وقایع دنیای حقیقی انجام دهد، موضوع دیگری است. اما اساسا، دریافت پیش پرداخت از درخواست کننده ی داده راه های متنوعی دارد. موضوع جالب اینجاست که با اینکه نمی توانیم قرارداد هوشمند «پرتاب تاس» را بنویسیم، اما این امکان وجود دارد که بتوان قرارداد هوشمندی نوشت که نسبت به پرتاب تاس از خود واکنش نشان دهد، همانطور که توسط oracle انجام شد.
