معماری برنامه های غیر متمرکز: پایان عقب ، الگوهای امنیتی و طراحی

برنامه های غیر متمرکز یا ðAPPS برای دستیابی به امنیت و قابلیت اطمینان بالا به یک طراحی سیستم ویژه نیاز دارند. در این مقاله می خواهم چندین اصل اصلی در مورد چگونگی طراحی و اجرای صحیح قراردادهای پایان و هوشمند برای برنامه های غیر متمرکز را پوشش دهم ، و اتریوم را به عنوان یک نمونه اصلی ، هرچند که بخش عمده ای از آن در مورد EOS ، TRON و سایر سیستم عامل های داده غیر متمرکز اعمال می شود.

نکات برجسته مقاله:

• نحوه ذخیره کلیدهای خصوصی در انتهای عقب بدون نگرانی های امنیتی
• چگونه می توان قراردادهای هوشمند را به درستی طراحی کرد و چه چیزی را "غیر متمرکز" کرد
• نمونه های معماری برنامه های کاربردی غیر متمرکز و نیمه متمرکز
• نحوه برخورد با مطالب سطح پایین مانند بار شبکه و خرابی ها

این بزرگ خواهد بود ، بگذارید این کار را انجام دهیم!

برنامه های غیر متمرکز و blockchain

با وجود این واقعیت که Blockchain امروز با مشکلات اتخاذ و تنظیم زیادی روبرو است ، این یک نوع فناوری است که برای ماندن در اینجا وجود دارد ، خواه blockchain ، hashgraph ، tempo یا هر فناوری لجر توزیع شده دیگر ، صرف نظر از الگوریتم.

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

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

سیستم عامل های Ethereum/EOS/Tron/… ، بر خلاف بیت کوین ، یک لایه برنامه پیچیده تر را پیاده سازی می کنند ، که به نوبه خود محیط اجرای را پیاده سازی می کند و به هر کسی امکان می دهد برنامه های غیرمتمرکز خود را در بالای سکو بنویسد. این برنامه های تعریف شده توسط کاربر همیشه مطابق طراحی و بدون هیچ گونه استثنائی اجرا می شوند و امنیت آنها توسط این سیستم عامل تضمین می شود.

برنامه های غیر متمرکز

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

اگر کسی از من خواسته بود که امروز چگونه کار کند ، من احتمالاً این را ترسیم می کردم

برای تصور آنچه امروز ما برنامه های غیر متمرکز می نامیم ، از هر منبع وب متمرکز موجود مانند _youtube_ یا _instagram_ به عنوان نمونه استفاده کنید و تصور کنید که به جای یک حساب متمرکز محافظت شده با رمز عبور ، "هویت رمزنگاری" خود را به منبع وب/تلفن همراه محدود می کنید.

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

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

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

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

هیچ راهی برای ساختن یک برنامه ایمن و جزئی غیرمتمرکز بدون استفاده از یک انتهای محکم از امروز وجود ندارد و کل این مقاله توضیح نحوه انجام این کار درست است.

(د) تمرکز و نشانه ها

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

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

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

نمونه های بسیاری از برنامه های کاربردی وجود دارد که در اطراف نشانه ها ساخته شده است: از بسیاری از بازی های جمع آوری شده مانند Cryptokitties (نشانه های ERC721) گرفته تا برنامه های خدمات محور تر مانند شبکه Loom ، یا حتی مرورگرهایی مانند سیستم عامل های شجاع و بازی مانند DreamTeam (نشانه های سازگار با ERC20).

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

انتهای برگشت برای شبکه های غیر متمرکز

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

در برنامه های کاملاً غیر متمرکز امروز ، جایی که مشتری ها مستقیماً با قراردادهای هوشمند در تعامل هستند ، این پل به قابلیت API JSON RPC از API های عمومی یا استخرهای گره مانند Infura کاهش می یابد ، که به نوبه خود به دلیل این واقعیت که همه دستگاه نمی توانند وجود داشته باشند. گره شبکه فردی خود را اجرا و پشتیبانی کنید. با این حال ، این API تنها مجموعه ای از کارکردهای اساسی و بسیار باریک را ارائه می دهد ، که به سختی امکان تهیه نمایش داده های ساده و نه داده های جمع آوری کارآمد را فراهم می کند. به همین دلیل ، در نهایت ، انتهای پشتی سفارشی وارد می شود و باعث می شود برنامه نیمه متمرکز شود.

بسته به نیاز برنامه ، کل تعامل با شبکه غیرمتمرکز فقط به یک یا دو نقطه کاهش می یابد:

1. گوش دادن به رویدادهای شبکه (مانند نقل و انتقالات توکن) / خواندن حالت شبکه.
2. انتشار معاملات (استناد به توابع قرارداد هوشمند تغییر دولت مانند انتقال توکن).

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

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

در عمل ما ، همه اینها باعث شد تا ما یک راه حل محکم و عقب برای اتریوم ایجاد کنیم که ما از آن Ethereum Gateway نام می بریم. این خدمات میکروسروس های دیگر را از سرگرمی Ethereum خلاصه می کند و یک API قابل اعتماد برای همکاری با آن فراهم می کند.

به عنوان یک راه اندازی سریع در حال رشد ، ما به دلایل واضح نمی توانیم راه حل کامل (هنوز) را فاش کنیم ، اما من قصد دارم همه چیزهایی را که شما باید بدانید برای ایجاد کاربرد غیر متمرکز خود بی عیب و نقص به اشتراک بگذارم. با این حال ، اگر سؤال یا سوالات خاصی دارید ، با من تماس بگیرید. نظرات این مقاله نیز بسیار مورد استقبال قرار می گیرد!

نظارت بر پایان برای اتریوم. این مانیتور فعالیت هایی را که عمدتاً در مورد ویژگی صورتحساب مکرر ما نشان می دهد ، نشان می دهد (اگرچه می توانید قله هایی را که هر ساعت اتفاق می افتد ببینید).

معماری برنامه های غیر متمرکز

این بخش از مقاله به نیازهای یک برنامه غیر متمرکز خاص بستگی دارد ، اما ما سعی خواهیم کرد برخی از الگوهای تعامل اساسی را در بالای آن مرتب کنیم که این برنامه ها ساخته شده اند (ðplatform = سکوی غیر متمرکز = Ethereum/EOS/tron/هر چیز دیگری):

مشتری ⬌ platform: برنامه های کاملاً غیر متمرکز.

مشتری (مرورگر یا برنامه موبایل) مستقیماً با کمک نرم افزارهای Ethereum "کیف پول" مانند Metamask ، Trust یا کیف پول سخت افزاری مانند Trezor یا Ledger با سکوی غیر متمرکز صحبت می کند. نمونه هایی از ساخت DAPP ها به این ترتیب عبارتند از cryptokitties ، تماس تفویض شده Loom ، کیف پول های رمزنگاری (Metamask ، Trust ، Tron Wallet ، دیگران) ، مبادلات رمزنگاری غیر متمرکز مانند Etherdelta و غیره.

ðplatform ⬌ مشتری ⬌ انتهای برگشت ⬌ ð پلاتفورم: برنامه های متمرکز یا نیمه متمرکز.

تعامل مشتری با پلت فرم غیر متمرکز و سرور ارتباط چندانی ندارد. مثال خوب این ، هر مبادله رمزنگاری (متمرکز) امروز است ، مانند Bitfinex یا Poloniex: ارزهایی که در مبادله ها تجارت می کنید به سادگی در پایگاه داده سنتی ثبت می شوند. شما می توانید با ارسال دارایی به یک آدرس خاص (ðplatform ⬌ مشتری) ، تعادل پایگاه داده خود را "بالا" و سپس دارایی ها پس از برخی اقدامات در برنامه (انتهای عقب ⬌ پلاتفورم) برداشت کنید ، با این حال ، هر کاری که شما از نظر "ðAPP" انجام می دهیدخود (مشتری ⬌ پایان عقب) به معنای تعامل مستقیم شما با ðplatform نیست.

مثال دیگر Etherscan. io است که از رویکرد نیمه متمرکز استفاده می کند: شما می توانید تمام اقدامات غیرمتمرکز مفید را در آنجا انجام دهید ، اما خود برنامه بدون پایان جامع پشتی آنها معنی ندارد (Etherscan به طور مداوم معاملات را همگام می کند ، داده ها را تجزیه می کند و آن را ذخیره می کند ،در نهایت تهیه یک API/UI جامع).

چیزی در این بین: هنوز ، برنامه های متمرکز یا نیمه متمرکز.

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

امیدوارم که الگوی تعامل برنامه های کاملاً غیر متمرکز (مشتری ⬌ platform) هیچ سؤالی ایجاد نمی کند. با تکیه بر چنین خدمات شگفت انگیز مانند Infura یا Trongrid می توانید به سادگی یک برنامه کاربردی بسازید که به هیچ وجه به سرور احتیاج ندارد. تقریباً تمام کتابخانه های سمت مشتری مانند Ethers. js برای Ethereum یا Tron-Web برای TRON می توانند به این خدمات عمومی متصل شوند و با شبکه ارتباط برقرار کنند. با این حال ، برای نمایش داده ها و وظایف پیچیده تر ، ممکن است به هر حال نیاز به اختصاص سرور خود داشته باشید.

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

نمونه ای از واکنش سرور به عملکرد کاربر در شبکه غیرمتمرکز

از دیدگاه پشتی در اینجا اتفاق می افتد:

1. ما با نظرسنجی مداوم شبکه به یک رویداد شبکه خاص گوش می دهیم.
2. پس از یک رویداد ، برخی از منطق تجاری را انجام می دهیم و سپس تصمیم می گیریم در پاسخ معامله کنیم.
3. قبل از انتشار معامله ، ما می خواهیم اطمینان حاصل کنیم که احتمالاً استخراج خواهد شد (در اتریوم ، تخمین موفقیت آمیز گاز معامله به معنای این است که هیچ خطایی علیه وضعیت شبکه فعلی وجود ندارد). با این حال ، ما نمی توانیم تضمین کنیم که معامله با موفقیت استخراج می شود.
4. با استفاده از یک کلید خصوصی ، معامله را امضا و منتشر می کنیم. در اتریوم نیز باید قیمت گاز و محدودیت گاز معامله را تعیین کنیم.
5. پس از انتشار معامله ، ما به طور مداوم شبکه را برای وضعیت آن نظرسنجی می کنیم.
6. اگر خیلی طول بکشد و نمی توانیم وضعیت معامله را بدست آوریم ، باید دوباره آن را منتشر کنیم یا "سناریوی شکست" را ایجاد کنیم. معاملات به دلایل مختلف می توانند از بین بروند: احتقان شبکه ، کاهش همسالان ، افزایش بار شبکه و غیره در اتریوم ، می توانید امضاء مجدد معامله را با قیمت گاز متفاوت (واقعی) در نظر بگیرید.
7. بعد از اینکه در نهایت معامله خود را استخراج کردیم ، در صورت لزوم می توانیم منطق کسب و کار بیشتری را انجام دهیم. به عنوان مثال ، ما می توانیم خدمات دیگر را در مورد واقعیت انجام معامله به شما اطلاع دهیم. همچنین ، قبل از تصمیم گیری نهایی در مورد معامله ، انتظار برای چند تأیید را در نظر بگیرید: شبکه توزیع می شود و از این رو نتیجه می تواند در مدت چند ثانیه تغییر کند.

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

برنامه های غیر متمرکز به پایان می رسد

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

• گوش دادن به رویدادهای شبکه و خواندن داده ها از شبکه
• انتشار معاملات و نحوه انجام آن ایمن

گوش دادن به رویدادهای شبکه

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

به عنوان مثال ، در استاندارد معروف ERC20 Token Standard ، هر انتقال توکن باید رویداد انتقال را وارد کند ، بنابراین به برنامه های خارج از زنجیره اجازه می دهد تا بدانند که انتقال نشانه ای رخ داده است. با گوش دادن به این رویدادها می توانیم هرگونه اقدامات (دوباره) را انجام دهیم. به عنوان مثال ، برخی از عکسهای رمزنگاری موبایل هنگام انتقال نشانه ها به آدرس شما ، اعلان فشار/ایمیل را برای شما ارسال می کنند.

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

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

تحویل قابل اعتماد از رویدادهای اتریوم به کلیه خدمات پایان

این مؤلفه ها به روش زیر کار می کنند:

1. Sync Back Service End Service دائماً شبکه را رأی می دهد و سعی در بازیابی رویدادهای جدید دارد. هنگامی که برخی از رویدادهای جدید در دسترس است ، این رویدادها را به اتوبوس پیام ارسال می کند. پس از ارسال موفقیت آمیز رویداد به اتوبوس پیام ، همانطور که برای blockchain ، می توانیم آخرین رویداد رویداد را ذخیره کنیم تا دفعه بعد از این بلوک درخواست کنید. به خاطر داشته باشید که بازیابی بیش از حد بسیاری از وقایع به یکباره ممکن است منجر به درخواست همیشه شود ، بنابراین باید تعداد رویدادها/بلوک هایی را که درخواست می کنید از شبکه محدود کنید.
2. اتوبوس پیام (به عنوان مثال ، خرگوش MQ) این رویداد را به هر صف که به صورت جداگانه برای هر سرویس انتهایی تنظیم شده است ، هدایت می کند. قبل از انتشار رویداد ، Sync Back Service Ends Sync End Service کلید مسیریابی (به عنوان مثال ، آدرس قرارداد هوشمند + موضوع رویداد) را مشخص می کند ، در حالی که مصرف کنندگان (سایر خدمات پایان عقب) صف هایی را ایجاد می کنند که فقط برای رویدادهای خاص مشترک هستند.

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

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

انتشار معاملات

برای انتشار معامله به شبکه غیرمتمرکز ، چند مرحله وجود دارد که باید انجام دهیم:

1. تهیه معاملههمراه با داده های معامله ، این مرحله به معنای درخواست وضعیت شبکه به منظور یافتن اعتبار این معامله است و قرار است استخراج شود (برآورد گاز در اتریوم) و شماره پی در پی معامله (NONCE در اتریوم). برخی از کتابخانه ها سعی می کنند این کار را در زیر کاپوت انجام دهند ، با این حال ، این مراحل مهم هستند.
2. امضای معاملهاین مرحله به معنای استفاده از کلید خصوصی است. به احتمال زیاد ، در اینجا می خواهید راه حل مونتاژ کلید خصوصی (به عنوان مثال) را تعبیه کنید.
3. انتشار و انتشار معامله. یکی از نکات مهم در اینجا این است که معامله منتشر شده شما همیشه فرصتی برای گم شدن یا کاهش از شبکه غیرمتمرکز دارد. به عنوان مثال ، در اتریوم ، اگر ناگهان قیمت گاز شبکه افزایش یابد ، می توان معامله منتشر شده را کاهش داد. در این حالت ، شما باید معامله را دوباره ارسال کنید. علاوه بر این ، شما ممکن است بخواهید معامله را با سایر پارامترها (حداقل با قیمت گاز بالاتر) مجدداً مجدداً مجدداً مجدداً انجام دهید تا در اسرع وقت آن را استخراج کنید. بنابراین ، بازنویسی معامله می تواند به معنای امضا مجدد آن باشد ، اگر معامله جایگزینی قبلاً از قبل امضا نشده باشد (با پارامترهای مختلف).

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

1. کاربر عملکردی را در یک قرارداد هوشمند اجرا می کند ، که در نهایت به انتهای بازگشت می تواند یک معامله شارژ موفق را انجام دهد.
2. یک سرویس برگشت انتهایی مسئول یک کار خاص به رویداد کمک هزینه پرداخت می شود و معامله شارژ را منتشر می کند.
3. پس از استخراج معامله شارژ ، این سرویس برگشت انتهایی مسئول یک کار خاص از شبکه اتریوم یک رویداد دریافت می کند و منطق را انجام می دهد (از جمله تنظیم تاریخ شارژ بعدی).

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

انتشار معامله همیشه شامل استفاده از یک کلید خصوصی است. ممکن است تعجب کنید که آیا امکان ایمن نگه داشتن کلیدهای خصوصی وجود دارد یا خیر. خوب ، بله و نه. استراتژی های پیچیده بی شماری و انواع مختلف نرم افزار وجود دارد که امکان ذخیره کلیدهای خصوصی را در انتهای عقب کاملاً ایمن فراهم می کند. برخی از راه حل های ذخیره سازی کلید خصوصی از پایگاه داده های توزیع شده با Geo استفاده می کنند ، در حالی که برخی دیگر حتی استفاده از سخت افزار ویژه را پیشنهاد می کنند. با این حال ، در هر صورت ، آسیب پذیرترین نقطه از یک برنامه نیمه متمرکز جایی است که کلید خصوصی مونتاژ می شود و برای امضای معامله استفاده می شود (یا در صورت سخت افزار ویژه ، نقطه تحریک روش امضای معامله). از این رو ، از لحاظ تئوری ، هیچ راه حل قابل اعتماد 100 ٪ وجود ندارد که محافظت از ضد گلوله را در برابر به خطر انداختن کلیدهای خصوصی ذخیره شده امکان پذیر کند.

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

الگوی حساب های عملیاتی برای برنامه های غیر متمرکز ، جایی که برای حساب های پشتی خود به امنیت درجه نظامی احتیاج ندارید

به این ترتیب ، در صورت اضطراری:

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

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

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

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