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

ظهر بخیر، همه! من مدت زیادی است که توسعه Backend را انجام می دهم و در چند سال گذشته، بیشتر و بیشتر پروژه های مختلف بلاک چین (Solidity on EVM) می نویسم. غواصی در بلاک چین برای من آسان نبود و مغز باطن من چندین بار خراب شد، بنابراین تصمیم گرفتم دیدگاه خود را در مورد تغییر به توسعه بلاک چین به اشتراک بگذارم.

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

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

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

درباره بلاک چین و دلیل جالب بودن آن

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

رفتن به بلاک چین برای پول

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

یک توسعه دهنده باطن خوب چه کسی است؟

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

1. اگر توسعه‌دهنده بک‌اند باتجربه باشد، پس او راه‌حل‌های تولیدی را اجرا کرده است.
2. اگر او آن را در Prod اجرا کرده باشد، می داند که چگونه کار می کند و می داند که چه اتفاقی برای محصول تحت بار می افتد.
3. اگر او خدمات را تحت بار نگه داشته است، پس از کار افتادن و خرابی سرویس گرفتار شده است.
4. و اگر او گرفتار خرابی های سرویس شود، احتمالاً آنها را برداشته است.

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

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

رفتن به بلاک چین برای این فناوری

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

• گران است
• ناخوشایند
• ناخوشایند، نامفهوم

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

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

اما افسوس که ارتباط با کلمه "blockchain" نسبتا کسل کننده و یکنواخت است:

• بیت کوین
• سرمایه گذاری
• کلاهبرداری
• ETH، ریپل، {insert coin name}
• حبابی که در شرف ترکیدن است

اگر یک بسته پول کاغذی را داخل اجاق گاز بریزیم، اجاق به خوبی می سوزد و حتی پول برای مدتی گرما می دهد. اما این پوچ است.

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

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

نظریه توسعه بلاک چین

عدم تمرکز

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

بیایید تصور کنیم که یک بانک داریم که یک سرویس متمرکز است. من به این بانک دستور می دهم: "لطفا 100 دلار به این شخص منتقل کنید". بانک ثبت می کند که من 100 دلار کمتر دارم و دیگری 100 دلار بیشتر.

اما مشکل سرویس متمرکز چیست؟ یک مالک پشت این سرویس متمرکز هست، اینطور نیست؟ معمولاً برخی از شرکت های بزرگ، هلدینگ ها، مهم نیست. در مورد ما، بگذارید یک نفر باشد. این یک نفر می تواند بگوید: «بیایید این کار را انجام دهیم. بگذارید الکس 100 دلار بفرستد، اما هیچکس این 100 دلار را دریافت نخواهد کرد. من بیشتر به آنها نیاز دارم.»

خدمات متمرکز صاحبان خود را دارند. مشکل این است که مالک می تواند تصمیمات منفی بگیرد و پول را از بین ببرد. و این می تواند نه تنها در مورد "گرفتن پول برای خود" باشد. به عنوان مثال، می توانید بنویسید: "ما 100500 دلار در بانک داریم" و امیدوار باشید که همه سپرده گذاران به دنبال آن پول نروند... همانطور که با SVB و سایر بانک هایی که مردند اتفاق افتاد.

بیت کوین برای تمرکززدایی مدیریت پول اختراع شد.

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

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

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

در قیاس اتاق، فریاد می زنم: "من 100 دلار به سام منتقل می کنم." همه ثبت می کنند که من 100 دلار کمتر دارم و سم 100 دلار بیشتر. اگر به طور ناگهانی، قبل از انتقال، کمتر از 100 دلار داشته باشم، کسی معامله را ثبت نمی کند.

قراردادهای هوشمند

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

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

چگونه با درخواست های خاصی که به این قرارداد هوشمند ارسال می شود رسیدگی کنیم؟ اگر قیاسی با backend ترسیم کنیم، سرویسی است که می تواند درخواست های POST و GET را پردازش کند. POST اطلاعات را ذخیره می کند. GET here اطلاعاتی را که ذخیره کرده‌ایم برمی‌گرداند. معمولاً هر باطن به این شکل است که ساختار می یابد.

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

به عنوان مثال کاربر 1 می آید و از طریق روش POST محتوا را ذخیره می کند (مثلاً پست). سپس کاربر 2 می آید و با استفاده از روش GET این محتوا را بازیابی می کند. کاربران نمی دانند کجا و چگونه نهفته است - باطن یک جعبه سیاه برای آنها است.

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

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

اگر بلاک چین و باطن را مقایسه کنیم، تصویر به شرح زیر است:

• در سرویس های مرسوم، ما به صورت رایگان می نویسیم، رایگان می خوانیم و به صورت وابسته
• در بلاک چین ما با پرداخت هزینه می نویسیم و به صورت رایگان و مستقل مطالعه می کنیم

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

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

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

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

به طور کلی، اساسی است، اما ارزش آن را دارد که در نظر داشته باشید - در صورت تغییر داده ها، باید برای هر عطسه هزینه کنید. به هر حال، استقرار قرارداد نیز یک رکورد در بلاک چین است و ارزان نیست!

استقرار یک قرارداد هوشمند

در دنیای باطن، من تقریباً به چرخه عمر توسعه ویژگی های زیر عادت دارم:

• کد را نوشت
• آن را در Gitlab راه اندازی کرد
• GitLab CI تست هایی را اجرا می کند، همه چیز را بررسی می کند
• اگر همه چیز خوب باشد، CI شروع به استقرار نسخه جدیدی از برنامه در سرور می کند

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

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

سپس، سرور سرویس گیرنده/سرویس با هر یک از گره ها تماس می گیرد تا اطلاعات قرارداد را دریافت یا ذخیره کند.

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

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

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

ذخیره سازی داده ها

بیایید در مورد ذخیره سازی اطلاعات صحبت کنیم. همه ما به داشتن PostgreSQL ، MySQL ، MongoDB ، Redis و سایر سرویس‌ها در پشتیبان عادت کرده‌ایم که به ما امکان می‌دهند به راحتی با داده‌ها کار کنیم. در مورد بلاک چین، چیزی شبیه به آن حتی نزدیک وجود ندارد.

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

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

برای مثال، اگر بخواهیم نه فقط در یک آرایه ذخیره کنیم؟ و ما می خواهیم اطلاعات را با کلید ذخیره کنیم - نقشه برداری برای آن وجود دارد.

علامت دلار به دلیلی ترسیم شده است - کمیسیون شبکه برای هر مجموعه گرفته می شود.

درد و درد

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

توجه به این نکته مهم است که اکثر "دردها" به دلایلی منطقی قابل درک هستند. اما این دردهای مغز باطن من را برطرف نمی کند.

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

ما نمی‌توانیم همه چیزهای مفید مرتب‌سازی کلید را نیز دریافت کنیم.

ورود به سیستم

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

در Typescript، من عادت دارم که فقط console.log(a) بنویسم و فوراً خروجی را در کنسول دریافت کنم. در Solidity، console.log وجود دارد که فقط هنگام اجرا در محیط توسعه hardhat محلی کار می کند. و آنچه که عالی است این است که بعد از اینکه آنچه را که نیاز دارم تقسیم کردم، باید همه این گزارش‌ها را قبل از استقرار قرارداد حذف کنم زیرا در غیر این صورت، قرارداد وزن بیشتری دارد و هزینه بیشتری برای استقرار دارد و اصلاً روی پرود کار نخواهد کرد. .

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

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

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

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

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

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

کار با رشته ها

در اینجا برای من یک شگفتی وجود داشت - کار با رشته ها به طور معمول غیرممکن است. بلاک چین برای رشته ها ایجاد نشده است. بیایید به سراغ مثال ها برویم.

کد زیر بدون هیچ مشکلی کار می کند.

و این کد دیگر کار نخواهد کرد:

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

اگر واقعاً به طول یک رشته نیاز دارید، می توانید آن را به بایت تبدیل کنید و سپس تعداد بایت ها را بشمارید. اما مشکل این است که برخی از کاراکترهای خاص به بایت 1v1 تبدیل نمی شوند. و برخی به سادگی تبدیل نمی شوند و ممکن است تراکنش خراب شود.

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

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

مشکل تماس خارجی

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

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

و وظیفه بی اهمیت "به دست آوردن دمای فعلی در خارج" چیزی غیرممکن می شود. در حالی که ما همیشه به آب و هوا نیاز نداریم، برخی از داده ها (مانند نرخ ارز یا وضعیت فعلی برخی از سیستم های خارجی) ضروری است. راه حل در رویکرد زیر نهفته است:

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

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

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

در پایان، در حال حاضر در معامله دوم، کل زنجیره به دلیل کمبود گاز برای معامله از بین می رود. چنین "باغ سبزیجات" در اطراف تماس های خارجی چنین پروژه هایی را پیچیده تر می کند. به احتمال زیاد، اگر ارتباط سختی با دنیای خارج دارید، نباید بلاک چین را برای پروژه خود انتخاب کنید.

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

این واقعیت که مقدار متغیر block.timestamp توسط بلاک ماینر تنظیم شده است، شایسته توجه ویژه است. البته تصور اینکه ماینر از قبل بداند که اوست که بلوک را استخراج می کند دشوار است و می تواند زمان را جایگزین کند. با این حال، یک احتمال فرضی وجود دارد. این خطر در زمینه 15 ثانیه مطرح است و اگر به دقایق و فواصل زمانی زیاد تکیه کنیم، چنین مشکلی وجود ندارد.

مسائل امنیتی

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

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

متغیرهای تغییرناپذیر

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

پس از استقرار این قرارداد و باز کردن آن از طریق دیکامپایلر، موارد زیر را مشاهده می کنیم:

یعنی بلافاصله این مقدار متغیر را دریافت می کنیم.

متغیرهای خصوصی

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

amount متغیر را خصوصی نامیدیم. قرارداد هوشمند را مستقر کنید و سپس ارزش آن را با یک قطعه کد ساده استخراج کنید:

در نهایت می توانید هر چیزی را از این طریق بیرون بکشید. پس به فکر ذخیره چیزهای حساس در قرارداد هوشمند نباشید!

استقرار قرارداد هوشمند

اساساً غیرممکن است که تغییرات خود را به عقب برگردانید. یک قرارداد هوشمند یک بار واگذار می شود و هیچ چیز قابل تغییر نیست. تا پایان زمان و سپس مقداری روی بلاکچین باقی خواهد ماند.

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

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

1. اولین نسخه قرارداد (Contract V1) ارسال شده است

2. یک قرارداد پروکسی ارسال شده است و وظیفه زیر را دارد: ارسال همه درخواست‌های 1v1 به قرارداد V1 یا استفاده از فضای ذخیره‌سازی خود و استفاده از منطق از قرارداد هدف.

3. علاوه بر این، کاربر با قرارداد پروکسی به همان روشی که با قرارداد اصلی ارتباط برقرار می کند.

   اگر نیاز به به روز رسانی قرارداد باشد، ادمین Contract V2 را مستقر می کند و از طریق admin-contract به پروکسی-قرارداد می گوید که اجرای آن اکنون در آدرس Contract V2 است.

4. در مرحله بعد، کاربر همچنین با پروکسی ارتباط برقرار می کند و مکانیک های Contract V2 قبلاً اجرا شده اند.

5. در مرحله بعد، کاربر همچنین با پروکسی ارتباط برقرار می کند و مکانیک Contract V2 قبلاً اجرا شده است.

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

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