شش جنبه منحصر به فرد از ton blockchain که توسعه دهندگان استحکام را شگفت زده می کند

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

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

انتقال از داده ها به داده های بزرگ

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

در اینجا شش جنبه منحصر به فرد از ton blockchain وجود دارد که احتمالاً بیشتر توسعه دهندگان استحکام را شگفت زده می کند:

1. قرارداد هوشمند شما نیاز به پرداخت اجاره و شارژ کاربران خود دارد

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

حرکت از یک بانک به یک پیام رسان فوری

مدل هزینه در تن کاملاً متفاوت است. به جای تقلید از حساب بانکی ، Ton از برنامه های وب مانند پیام رسان های فوری الهام گرفته شده است. چه کسی هزینه ارسال پیام در Facebook Messenger را پرداخت می کند؟قطعاً شخصی نیست که انتقال را آغاز می کند. توسعه دهنده برنامه ، Facebook Inc (یا Meta Inc ، من دنبال نمی کنم ، من خودم از تلگرام استفاده می کنم) ، در واقع هزینه ها را پوشش می دهد ، و این وظیفه Facebook Inc است که این هزینه ها را به نوعی بازیابی کند و خود را تأمین کند. به طور خاص ، در تن ، در تن ،DAPP خود باید هزینه های منابع خود را بپردازد. هر قرارداد هوشمند یک توازن توکن را در اختیار دارد و از این مانده برای پرداخت اجاره استفاده می کند. اگر قرارداد هوشمند از پول خارج شود ، سرانجام حذف می شود (نگران نباشید ، همه چیز قابل بازیابی است). توجه کنید که پرداخت هزینه ذخیره سازی زنجیره ای یک بار اتفاق نمی افتد ، پرداخت اجاره مداوم است. اگر فقط برای مدت کوتاهی داده ها را نگه دارید ، به طور قابل توجهی کمتر پرداخت خواهید کرد. این اقتصاد هزینه بیشتر مطابق با هزینه های معدنچیان است و بنابراین مقیاس آسان تر است. بسیار شبیه به Facebook Inc ، توسعه دهنده قرارداد در TON آزادی زیادی برای انتخاب چگونگی تأمین بودجه عملکرد خود دارد. توسعه دهنده می تواند قرارداد را با توکن های تن از جیب تأمین کند و کاربران خود را یارانه دهد. یا می تواند برای اقدامات مختلف گاز را از کاربران شارژ کند و این گاز را در تراز خود برای پرداخت اجاره های بعدی نگه دارد.

2. تماس های بین قراردادهای هوشمند ناهمزمان است و اتمی نیست

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

حرکت از یک سرور واحد به یک خوشه میکروسرویس

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

3. قرارداد هوشمند شما نمی تواند روش های دریافت کننده را در سایر قراردادها اجرا کند

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

حرکت از یک سرور واحد به یک خوشه میکروسرویس

وقتی میکروسرویس‌های جداگانه‌ای داریم که روی ماشین‌های مختلف اجرا می‌شوند، خواندن حافظه حالت در سرویس‌ها ناگهان غیرممکن است. قراردادهای هوشمند در TON فقط می توانند با ارسال پیام های ناهمزمان ارتباط برقرار کنند. اگر نیاز به پرس و جو از داده های قرارداد دیگری دارید و فوراً به پاسخ نیاز دارید، شانس شما را ندارید. در واقع عجیب تر می شود. اگر روش‌های گیرنده را در قرارداد هوشمند TON می‌بینید، مانند getBalance - این روش‌ها از سایر قراردادهای هوشمند قابل دسترسی نیستند. روش‌های Getter را فقط مشتریان خارج از زنجیره می‌توانند فراخوانی کنند، مشابه این که کیف پول اتریوم شما می‌تواند از یک گره کامل مانند Infura برای پرس و جو از هر وضعیت قرارداد هوشمند استفاده کند.

4. کد قرارداد هوشمند تغییرناپذیر نیست و به راحتی قابل تغییر است

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

انتقال از وکلا به مهندسین نرم افزار

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

5- شما نباید ساختارهای داده بدون مرز را در وضعیت قرارداد خود داشته باشید

این یک مشکل دشوار است که مدتی طول می کشد ، اما توضیح می دهد که چرا برخی از قراردادهای هوشمند روی تن به شکلی که وجود دارند معمار می شوند. ساختار داده های مجروح متغیرهای دولتی در قراردادهای هوشمند هستند که می توانند به طور نامحدود رشد کنند. قرارداد ERC20 را در اجرای نشانه USDC در نظر بگیرید. این قرارداد نیاز به حفظ نقشه مانده در هر آدرس کاربر دارد. تعداد دارندگان مختلف USDC می توانند به طور نامحدود رشد کنند زیرا USDC را می توان در مقادیر زیادی استخراج کرد و به قطعات ریز تقسیم کرد. به عبارت دیگر ، تعداد کلیدهای موجود در نقشه می تواند به همان اندازه که می خواهید باشد. چه اتفاقی می افتد اگر یک مهاجم با اضافه کردن مطالب بیشتر و بیشتر ، قرارداد را اسپم کند؟آیا آنها قادر به ایجاد حمله به DOS هستند و از استفاده دیگر کاربران صادق از استفاده از این قرارداد جلوگیری می کنند؟Ethereum این مشکل را کاملاً ظریف برای توسعه دهندگان قرارداد هوشمند حل می کند. مدل هزینه Ethereum نشان می دهد که کاربر که داده های حالت جدید را می نویسد ، هزینه این داده ها را پرداخت می کند. این بدان معناست که مهاجم ما برای هرزنامه خود باید هزینه بالایی بپردازد. علاوه بر این ، هزینه گاز برای نوشتن به نقشه در اتریوم ثابت است و به میزان داده این نقشه بستگی ندارد ، به این معنی که سایر کاربران از هرزنامه رنج نمی برند. نکته آخر این است که نقشه های اسپم در اتریوم اقتصادی نیست و محافظت توسط سیستم ارائه می شود.

حرکت از نقشه های بدون مرز به قراردادهای بدون مرز

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

6. کیف پول قراردادها هستند و یک کلید عمومی می تواند کیف پول های متلاشی را مستقر کند

در Ethereum ، کیف پول کاربر مترادف با آدرس آنها است و یک آدرس مستقیماً از یک کلید عمومی (و کلید خصوصی مربوط به آن) گرفته می شود. این یک رابطه 1: 1 است ، یک آدرس برای هر کلید عمومی و یک کلید عمومی در هر آدرس وجود دارد. تا زمانی که کاربر کلید خصوصی خود را بشناسد ، آنها هرگز نمی توانند کیف پول خود را از دست بدهند. علاوه بر این ، کاربر در Ethereum برای داشتن کیف پول دیگر نیازی به انجام کار خاصی ندارد. آدرس اتریوم کیف پول است. آدرس می تواند ETH ارز بومی را نگه دارد ، آدرس می تواند نشانه های ERC20 و NFT ها را در خود نگه دارد و آدرس می تواند معاملات را به طور مستقیم به سایر قراردادهای هوشمند ارسال و امضا کند.

حرکت از آدرس به قرارداد

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