مسابقه قرارداد هوشمند: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

بیش از یک راه برای قرار دادن کد در بلاک چین وجود دارد

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

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

در این مقاله، هدف من بررسی برخی از تفاوت‌های عمده بین رویکردهای قرارداد هوشمند و مبادلاتی است که آنها نشان می‌دهند. من این کار را با نگاهی به چهار پلتفرم محبوب بلاک چین سازمانی انجام می دهم که از نوعی کد سفارشی شده روی زنجیره پشتیبانی می کنند. اول، IBM پارچه ای هیجان انگیز، که قراردادهای خود را "کد زنجیره ای" می نامد. دوم، پلت فرم MultiChain ما، که معرفی می کند فیلترهای هوشمند در نسخه 2.0 سوم، Ethereum (و مجاز است کوروم و سوراخ spin-offs)، که نام "قرارداد هوشمند" را رایج کرد. و در نهایت، R3 Corda، که در معاملات خود به "قراردادها" اشاره می کند. علیرغم همه اصطلاحات مختلف، در نهایت همه اینها به یک چیز اشاره دارند - کد ویژه برنامه که قوانین یک زنجیره را تعریف می کند.

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

اصول اولیه بلاک چین

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

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

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

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

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

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

بیایید با قوانین تراکنش، اولین مورد از این چالش ها، شروع کنیم و ببینیم که چگونه آنها به ترتیب در Fabric، MultiChain، Ethereum و Corda بیان می شوند.

قوانین معاملات

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

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

ورودی ها و خروجی ها

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

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

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

لازم به ذکر است که علیرغم به اشتراک گذاری مدل ورودی-خروجی، MultiChain و Corda آن را بسیار متفاوت پیاده سازی می کنند. در MultiChain، خروجی ها می توانند دارای دارایی ها و/یا داده ها در قالب JSON، متن یا باینری باشند. قوانین در «فیلترهای تراکنش» یا «فیلترهای جریان» تعریف شده‌اند، که می‌توان آن‌ها را برای بررسی همه تراکنش‌ها یا فقط آنهایی که شامل دارایی‌های خاص یا گروه‌بندی داده‌ها هستند، تنظیم کرد. در مقابل، یک "وضعیت" خروجی Corda با یک شی در زبان برنامه نویسی جاوا یا کاتلین، با فیلدهای داده تعریف شده نشان داده می شود. قواعد کوردا در «قراردادهایی» تعریف می‌شوند که به حالت‌های خاصی متصل می‌شوند، و قرارداد یک ایالت فقط در مورد معاملاتی اعمال می‌شود که آن حالت را در ورودی‌ها یا خروجی‌های خود دارند. این مربوط به کوردا است مدل دید غیر معمول، که در آن تراکنش‌ها فقط توسط طرف‌های مقابلشان یا کسانی که معاملات بعدی آنها را تحت تأثیر قرار می‌دهند قابل مشاهده هستند.

قراردادها و پیام ها

رویکرد دوم، که من آن را "مدل قرارداد-پیام" می نامم، در Hyperledger Fabric و Ethereum استفاده می شود. در اینجا، چندین «قرارداد هوشمند» یا «کدهای زنجیره‌ای» را می‌توان بر روی بلاک چین ایجاد کرد و هر کدام پایگاه داده و کد مرتبط خود را دارند. پایگاه داده یک قرارداد فقط با کد آن قابل تغییر است و نه مستقیماً توسط تراکنش های زنجیره بلوکی. این الگوی طراحی شبیه به "کپسوله کردن" کد و داده در برنامه نویسی شی گرا است.

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

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

قوانین نمونه

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

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

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

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

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

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

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

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

قوانین داخلی

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

به عنوان مثال، MultiChain مجوزهای اتصال به شبکه، ارسال و دریافت تراکنش ها، ایجاد دارایی ها یا جریان ها یا کنترل مجوزهای سایر کاربران را مدیریت می کند. چندین دارایی قابل تعویض را می توان به صورت ایمن و اتمی صادر، انتقال، بازنشسته یا مبادله کرد. هر تعداد "جریان" را می توان در یک زنجیره ایجاد کرد، برای انتشار، نمایه سازی و بازیابی داده های درون زنجیره ای یا خارج از زنجیره در قالب های JSON، متنی یا باینری. همه قوانین تراکنش برای این انتزاع ها خارج از جعبه در دسترس هستند.

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

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

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

قوانین معاملات	پارچه	چند زنجیره ای	Ethereum	کوردا
مدل	قرارداد-پیام	ورودی خروجی	قرارداد-پیام	ورودی خروجی
ساخته شده	هیچ	مجوزها + دارایی ها + جریان ها	هیچ	هیچ

تعیین کننده

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

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

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

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

منابع عدم جبر

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

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

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

اجرای قطعی

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

فیلترهای MultiChain و قراردادهای Corda با تطبیق زبان‌های برنامه‌نویسی موجود و محیط‌های زمان اجرا، رویکرد متفاوتی را انتخاب می‌کنند. MultiChain از جاوا اسکریپت در حال اجرا در گوگل استفاده می کند V8 موتور، که هسته مرورگر کروم و پلتفرم Node.js را نیز تشکیل می‌دهد، اما منابع غیر جبرگرایی غیرفعال است. به طور مشابه، Corda از جاوا یا استفاده می کند کوتلین، که هر دو به "بایت کد جاوا" کامپایل می شوند که در یک ماشین مجازی جاوا ("JVM") اجرا می شود. در حال حاضر، Corda از JVM غیر قطعی استاندارد Oracle استفاده می‌کند، اما کار برای ادغام یک نسخه قطعی. در این بین، توسعه دهندگان قرارداد Corda باید مراقب باشند که در کد خود غیر قطعی بودن را مجاز نکنند.

چگونه خالص بودن اتریوم با رویکرد تکاملی MultiChain و Corda مقایسه می شود؟ مزیت اصلی اتریوم به حداقل رساندن ریسک است - یک ماشین مجازی ساخته شده برای هدف کمتر احتمال دارد که منبع غیرعمدی غیر جبرگرایی داشته باشد. در حالی که هر گونه نظارتی را می توان با یک به روز رسانی نرم افزار برطرف کرد، برای هر زنجیره ای که به اندازه کافی بدشانس بود با آن مواجه شد اختلال ایجاد می کرد. با این حال، مشکل اتریوم این است که Solidity و EVM یک اکوسیستم کوچک و نوپا را در زمینه گسترده‌تر زبان‌های برنامه‌نویسی و محیط‌های زمان اجرا تشکیل می‌دهند. در مقایسه، جاوا اسکریپت و جاوا هستند دو زبان برتر در Github، بر روی میلیاردها دستگاه دیجیتال اجرا می شود و دارای زمان اجرا است که طی چندین دهه بهینه شده است. احتمالاً به همین دلیل است که بلاک چین عمومی اتریوم در حال بررسی انتقال به آن است ewas، یک فورک قطعی از استاندارد در حال ظهور WebAssembly.

جبر با تأیید

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

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

برای روشن شدن تفاوت، جبرگرایی در بیشتر پلتفرم‌های بلاک چین بر این سوال استوار است: "نتیجه اجرای این کد بر روی این داده‌ها چیست؟" - و ما باید کاملاً مطمئن باشیم که هر گره به این سؤال یکسان پاسخ خواهد داد. در مقابل، جبرگرایی در Fabric بر اساس یک سوال متفاوت است: "آیا تایید کنندگان کافی در مورد نتیجه اجرای این کد بر روی این داده ها توافق دارند؟" پاسخ دادن به آن یک موضوع نسبتاً ساده برای شمارش است، و جایی برای غیر جبرگرایی وجود ندارد.

جبرگرایی فابریک پیامدهای جالبی دارد. اولاً، chaincode را می توان در بسیاری از زبان های برنامه نویسی مختلف نوشت، زیرا نیازی به تطبیق آنها برای جبر نیست (Go، Java و JavaScript در حال حاضر پشتیبانی می شوند). دوم، کد زنجیره‌ای را می‌توان از دید برخی از شرکت‌کنندگان بلاک‌چین پنهان کرد، زیرا فقط باید توسط مشتریان و تأییدکنندگان اجرا شود (پایگاه‌داده خود در سطح جهانی قابل مشاهده است). در نهایت و مهم‌تر از همه، Fabric chaincode می‌تواند کارهایی را انجام دهد که در سایر محیط‌های بلاک چین ممنوع هستند، مانند بررسی آب و هوا با استفاده از یک API آنلاین وب. در بدترین حالت، جایی که هر تایید کننده پاسخ متفاوتی از این API دریافت می کند، مشتری موفق به دریافت تاییدیه های کافی برای هر نتیجه خاص نمی شود و هیچ تراکنشی انجام نمی شود. (لازم به ذکر است که اعضای تیم فابریک هنوز توصیه با استفاده از منطق قطعی در داخل کد زنجیره ای، به منظور جلوگیری از غافلگیری.)

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

تعیین کننده	پارچه	چند زنجیره ای	Ethereum	کوردا
مدل	تاییدیه ها	زمان اجرا اقتباس شده	VM هدفمند	زمان اجرا اقتباس شده
زبان ها	برو + جاوا + جاوا اسکریپت	جاوا اسکریپت	solidity	جاوا + کاتلین
قابلیت مشاهده کد	طرف مقابل + تایید کنندگان	بلاکچین	بلاکچین	طرف مقابل + وابسته به
اجرا	نه	بله	بله	نه (فعلا)

پیشگیری از تعارض

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

دو مدل

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

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

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

خروجی ها در مقابل قراردادها

تاکنون دو تکنیک مختلف برای جلوگیری از تراکنش‌های متضاد دیده‌ایم – خروجی‌های تک‌خرجی در MultiChain و Corda، و تأیید مبتنی بر قرارداد در اتریوم. پس کدام بهتر است؟

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

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

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

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

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

مجموعه های خواندن و نوشتن

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

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

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

پیشگیری از تعارض	پارچه	چند زنجیره ای	Ethereum	کوردا
مدل	مجموعه های خواندن و نوشتن	خرج تنها	چک های قرارداد	خرج تنها
تایید	مستقل	مستقل	مستقل	دفاتر اسناد رسمی مورد اعتماد
سرعت	~ 10 ثانیه (تأیید)	~1s (تکثیر)	~ 10 ثانیه (تأیید)	0 تا 5 ثانیه (دفتر اسناد رسمی)

یک انتخاب پیچیده

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

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

لطفا هر نظری را ارسال کنید در LinkedIn.