توسعه راهکارهای بلاک چین ؛ قرارداد هوشمند ، یک پایگاه داده نیست!

کدگذاری قرارداد هوشمند (Smart Contract) به عنوان جدول‌های پایگاه داده اشتباه است. خود من نیز تا همین اواخر در این مورد اشتباه می‌کردم. توسعه راهکارهای بلاک چین (Blockchain) ، شما را ملزم می کند تا در مورد داده‌ها، کنترل و حریم خصوصی متفاوت فکر کنید.

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

یکی از جزییاتی که این اواخر توجه من را جلب کرد، این بود: این که داده‌ها هم در یک بلاک چین عمومی، عمومی هستند یعنی چه؟

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

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

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

ثبت وقایعی که در یک بلاک چین تولید شده‌اند

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

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

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

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

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

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

من حتی در مورد رویدادها فکر نمی‌کردم تا این که برناردو برگشت و گفت: “ثبت وقایعی که در یک بلاک چین تولید شده‌اند چطور است، آیا این مشکل شما را حل می‌کند؟”

این موضوع ذهن من را باز کرد.

کار با رویدادها

تا آن زمان من زیاد به رویدادهای اتریوم فکر نمی کردم. می‌دانستم هنگامی تغییر وضعیت بلاک چین، به جای بازگرداندن ارزش به انتشار یک رویداد کمک می کنید. همچنین یاد گرفته‌ام که آن رویدادها را از فرانت اند (front end) بگیرم تا نتیجه را بازیابی کنم. در مورد کارکرد رویدادها هیچ ایده‌ای نداشتم.

هنگامی که شما یک رویداد را از یک قرارداد هوشمند خارج می کنید، در بلاک چین نیمه ساختار یافته ثبت می‌شود. چند قسمت از این رویداد همیشه یکسان است و متغیرهایی که برای این رویداد در قرارداد هوشمند تعریف می‌کنید، به عنوان قسمت‌های اضافی پیوست می‌شوند. از نظر گس (gas)، یک رویداد یکی از ارزان‌ترین عملیات‌هایی است که می‌توانید در اتریوم انجام دهید. در واقع ۴۰۰۰ گس واقعا ارزان است.

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

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

در حال حاضر نحوه توسعه نرم‌افزار چگونه است

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

همه تغییرات وضعیت باید یک رویداد ایجاد کند.

با اطمینان از این که همه تغییرات وضعیت باعث ایجاد یک رویدادی می‌شود، لازم نیست نگران ردیابی تراکنش‌ها باشیم. تمام تغییرات وضعیت به عنوان رویدادهایی دامپ می‌شوند و ما تنها اطلاعات را که لازم داریم به طور خلاصه از Front End خواهیم داشت.

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

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

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

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

توجه داشته باشید که این قرارداد دوم هیچ چیزی را ذخیره نمی‌کند و عملکردی برای بازیابی داده‌‌ها نیز ندارد. با این حال کار کرده و همان کار را انجام می‌دهد.

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

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

می‌توانید در starter-kit نمونه‌ای از کش رویداد را پیدا کنید؛ لطفاً توجه داشته باشید، زیرا این ابزاری است که در حال حاضر در همه پروژه‌ها از آن استفاده می‌شود و باید به سرعت پیشرفت کند.

نتیجه گیری

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

داده‌ها را تنها در صورتی که یک قرارداد هوشمند به آن نیاز داشته باشد در حالت متغیر ذخیره کنید، زیرا در غیر این صورت در یک رویداد از بین می‌رود.

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

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