بلاکچین ساختار و بستر اصلی توسعه ارزهای دیجیتال موجود در بازارهای مالی دنیا است. از طرفی قابلیت‌های گسترده و جدید این تکنولوژی مانند شبکه غیر متمرکز، تغییر ناپذیری داده، شفافیت و قابلیت حسابرسی تراکنش‌ها باعث شده است تا تراکنش‌های اعمال شده بر پایه این تکنولوژی امن و غیر قابل تغییر باشند از این رو با افزایش آشنایی دنیای توسعه نرم‌افزار با این دست فناوری‌ها، میتوانیم گسترش استفاده از آن را در دیگر حوزه‌ها نیز مانند خدمات اجتماعی و مالی، مدیریت ریسک، خدمات بهداشتی و ... مشاهده کنیم. با این تفاسیر ما در این پژوهش سعی داریم تا در نرمافزارهایی که در حال استفاده از این تکنولوژی هستند را بررسی کرده و آن‌ها را در قالب الگوهای پر تکراری که در روزمره استفاده می‌شوند تا ویژگی‌های کیفی را به حد قابل قبولی برای کاربران برساند، تحلیل و دسته‌بندی کنیم.
در ادامه، در ادبیات موضوع مقدمه ای از بلاکچین و معماری نرم افزار گفته می شود. در بخش سوم، مفاهیم مورد توجه و تاثیر گذار در ویژگی های کیفی نرم افزار های مبتنی بر بلاکچین معرفی می شود و الگوهایی برای حل مشکلات و بهبود ویژگی های کیفی به همراه ارتباط آن ها با این مفاهیم، چرایی استفاده از آن ها، موارد استفاده و ابزار های آن ها ارائه می شود. در نهایت جمع بندی از کل مطالب و دستاورد های این پژوهش ارائه می شود.
بلاکچین یک شبکه نظیر به نظیر ذخیره اطلاعات است که مجموعه‌ای از تراکنش‌ها را به صورت امن و پیوسته، بدون نیاز به ایجاد امنیت توسط موجود ثالثی، به صورت غیر‌متمرکز ذخیره می کند. می‌توان به بلاکچین به صورت دفترچه‌ای از تراکنش‌های مالی نگاه کرد که پس از ثبت یک تراکنش در آن، امکان ایجاد تغییر و یا حذف آن وجود ندارد. در سال 2009، بیتکوین (Bitcoin) اولین شبکه بلاکچین برای استفاده گسترده معرفی شد که هم‌اکنون پیشتاز رمزارز‌هاست. امروزه از بلاکچین برای تبادل انرژی، حساب و کتاب مالی، رسانه و سرگرمی و خرید و فروش استفاده می شود.[1] در ادامه به‌صورت مختصر برخی مفاهیم مهم در بلاکچین را معرفی می‌کنیم.
قراردادهای هوشمند
قراردادهای هوشمند، کدها و برنامه‌هایی بر بستر بلاکچین هستند که تنها در شرایطی که برای آن برنامه‌ریزی شده‌اند، قابل اجرا هستند. این قابلیت باعث می‌شود که کسب و کار‌ها به صورت خودکار و بدون نیاز به موجود ثالثی برای تایید شرایط، مدیریت شود. فرض کنید آلیس (Alice) قصد خرید مقداری طلا از باب (bob) دارد. در روال عادی، باب می‌تواند پول را دریافت کند ولی از واگذاری طلا امتناع کند. همچنین ممکن است آلیس طلا را بدون پرداخت مبلغ دریافت کند. حتی در صورت معامله، هر دو طرف امکان تکذیب دارند. اما این معامله می تواند به صورت امن، خودکار و بدون امکان تکذیب، به کمک قراردادهای هوشمند بر بستر بلاکچین صورت گیرد.
نحوه ذخیره سازی داده‌ها
همانطور که مطرح شد، بلاکچین دفترچه از تراکنش هاست. این دفترچه دسته‌هایی از تراکنش‌ها به صورت پیوسته به هم متصل شده‌اند و هر دسته‌ی جدید از تراکنش تنها به انتهای دفترچه می‌تواند اضافه شود. تراکنش ها در دسته‌هایی به نام بلاک (block) ذخیره می‌شوند. اگرچه این مفهوم بین تمامی شبکه‌های بلاکچین مشترک است، اما فرمت ضبط و ثبت تراکنش‌ها بین آن‌ها می‌تواند متفاوت باشد. بطور کلی، بلاکچین‌ها در فرمت تراکنش‌های آن‌ها، به دو دسته مبتنی بر حساب (Account-based) و مبتنی بر خروجی (Utxo-based) تقسیم می شوند. در دسته اول، تراکنش ها به صورت انتقال ارز از یک حساب به حساب دیگر ذخیره می‌شود. این در حالی است که در دسته دوم، ارز ها در جعبه‌هایی هستند و یک تراکنش، تعدادی جعبه را در ورودی خرج می کند و تعدادی جعبه در خروجی می‌سازد و موجود هر حساب از ارز داخل جعبه‌های متعلق به آن حساب مشخص می شود.
پروتکل ثبت تراکنش جدید
تراکنش‌ها برای ثبت در شبکه، باید مورد تایید مجموعه‌ی گره‌های شبکه قرار گیرند. این گره‌ها برای تایید، از پروتکل مشخصی استفاده می‌کنند و نحوه انتخاب و روند ثبت تراکنش جدید در بلاکچین تاثیر مستقیمی بر سرعت، امنیت و مقیاس پذیری آن‌ها دارد. تقریبا همه‌ی بلاکچین‌ها یکی از دو مفهوم اثبات کار(Proof of work) و اثبات سهام(Proof of stake) را بکار می‌برند. در اثبات کار، هرکس که بتواند یک مقدار مشخصی را به همراه لیستی از تراکنش‌ها ارائه کند، تراکنش‌های او ثبت می‌شود. این مقدار مشخص که nonce نامیده می‌شود، داده‌ای از بلاک است که با هدف ایجاد یک بلاک با مقدار هش با خصوصیت خاصی مقدار دهی می‌شود. برای مثال، مقدار هش بلاک پیشنهادی، باید با عبارت aabbccddeeff شروع شود. ایجاد چنین بلاکی، تنها با امتحان کردن مقادیر مختلف برای nonce امکان پذیر است و توان محاسباتی زیادی نیاز دارد. در طرف مقابل، در اثبات سهام، افراد، متناسب با مقدار سهامی که دارند، به نوبت می‌توانند تراکنش‌های جدید را انتخاب کنند. این سهام‌ها براساس میزان ارز و یا توکنی است که فرد در قرارداد هوشمندی قفل (لاک) کرده است. شبکه اتریوم، یک شبکه مبتنی بر اثبات کار بود که در چند ماه اخیر به اثبات سهام تغییر پیدا کرده است. از شبکه‌های مبتنی بر اثبات کار نیز می‌توان از ارگو نام برد.
استیبل کوین‌ها (stable coins)
استیبل کوین‌ها، ارزهای دیجیتالی هستند که قیمت آن‌ها تقریبا ثابت است و ارزش آن‌ها توسط یک دارایی فیزیکی مانند واحد پولی یک کشور مثل دلار، یا طلا و غیره تعیین می‌شود. استیبل کوین‌ها برای تسهیل تبادلات مالی در سطح بلاک چین طراحی شده‌اند؛ به این معنی که مثلا برای پرداخت دلار به فرد دیگر از طریق بلاک چین، نیازی به خرید یک ارز دیجیتال به اندازه کافی متناسب با قیمت آن به دلار، خرید و انتقال آن به فرد مقابل به طریقی و سپس تبدیل ارز به دلار توسط فرد نیست و کافیست به مقدار لازم استیبل کوین به فرد واریز شود. از معروف ترین استیبل کوین‌ها می‌توان USDT [2] در شبکه TRON را نام برد که معادل یک دلار است. XAUt [3] نمونه‌ی دیگر از استیبل کوین‌هاست که معادل طلا است و به‌صورت توکن ERC-20 در شبکه اتریوم در دسترس است.
معماری نرم‌افزار با ارائه‌ی مجموعه‌ای از اسناد به معماران سیستم و ذی‌نفعان کمک می‌کند تا دید‌های متفاوتی از ساختار نرم‌افزار به صورت کلان در کوتاه‌ترین زمان داشته باشند و سعی می‌کند محتوایی را ارائه دهد تا مهندسین نرم‌افزار با استفاده از آن‌ها از بسیاری از تصمیمات اشتباه در مسیر توسعه‌ی محصول فاصله بگیرند و در اصل عامل پیشبینی شرایط دشوار برای ساخت و توسعه‌ی نرمافزارها باشد.
اما معماری نرم‌افزار در طرف دیگر مسیر توسعه، نقش واسط میان ذی‌نفعان و توسعه دهندگان نرم‌افزار را دارد؛ به شکلی که با استفاده از ابزار و مدل‌های گوناگون در هر بخش از نرم‌افزار نحوه و معیار رسیدن به اهداف و نیازمندی‌های نهایی کسب و کار را در سطوح بالای توسعه محصول به نمایش می‌گذارد. در واقع معماران در این حوزه سعی دارند تا برخی از ویژگی‌های توصیفی و غیر قابل سنجش از نرم‌افزار نهایی را با استفاده از معیار‌هایی به صورت تحلیلی و قابل فهم برای تمامی ذی‌نفعان ارائه کنند.
نیازمندی‌های کارکردی
این دسته از نیازمندی‌ها، در اصل همان مجموعه اعمال مهمی هستند که یک کاربر باید آن‌ها را انجام دهد تا به هدف نهایی که دریافت خدمات دلخواه خود هست، برسد. هر دو گروه توسعه دهندگان و ذی‌نفعان محصول باید کاملاً به این نیازمندی‌ها مسلط باشند و محیا کردن بستری برای ارائه خدمات مربوط به این نیازمندی‌ها از اولویت‌های اول آن‌ها باشد.
نیازمندی‌های غیر کارکردی
به صورت کلی خصوصیات کلی یک سیستم را شرح می‌دهند و در اصل می‌توان گفت که محقق نشدن آن‌ها باعث نمی‌شود که سیستم برای ارائه خدمات اصلی خود دچار مشکل شود ولی هرچه محصول به تحقق آن‌ها نزدیک‌تر شود، در واقع کیفیت نرم‌افزار خود را ارتقاع داده است.
در معماری نرم‌افزار، اگرچه تحقق نیازمندی‌های کارکردی در دستور کار قرار دارد، اما تمرکز اصلی در رسیدن به بهترین کیفیت قابل ارائه به ذی‌نفعان است.
· کارایی:
ارزیابی واکنش سیستم به برخی اتفاقات تأثیر گذار بر اجزای محیط نرم‌افزار که بیشتر به صورت اندازه‌گیری زمان پاسخ‌ها در یک بازه زمانی مشخص سنجش می‌شود.
· قابلیت یکپارچگی:
میزان تطبیق پذیر بودن سیستم مورد نظر برای برقراری ارتباط با دیگر نرمافزارهای خارجی که سنجش فاصله میان اجزای دو طرف در این بخش ارائه می‌شود.
· قابلیت استفاده:
یکی از مهم‌ترین ویژگی‌های کیفی، قابلیت استفاده است. این ویژگی مرتبط با استفاده‌ی کاربر از سیستم است و به بیان میزان رضایت کاربر از خدمات ارائه‌شده و سهولت استفاده از آن‌ها در فرایند می‌پردازد.
· قابلیت اطمینان:
معیاری برای ارزیابی میزان تحمل سیستم در یک شرایط از پیش تعیین شده، از جهت زیرساخت و یا خود لایه برنامه کاربردی
· امنیت:
معیاری برای ارزیابی میزان محافظت سیستم از داده‌ها در مقابل دسترسی عامل‌های غیر مجاز در عین ایجاد دسترسی مجاز برای افراد مشخص شده.
· قابلیت نگه‌داری:
مهارت و قابلیت سیستم برای پشتیبانی از ایجاد تغییرات در نرمافزارها که ممکن است به نیازمندی‌های قدیمی و یا به طور کل یک نیازمندی جدید باشد.
· تغییرپذیری:
بیانی از میزان تغییرات ناشی از ایجاد یک تغییر در سیستم است و به میزان انتشار تغییرات به دیگر قسمت‌ها می‌پردازد.
· آزمایش‌پذیری:
بیانی از میزان تغییرات ناشی از ایجاد یک تغییر در سیستم است و به میزان انتشار تغییرات به دیگر قسمت‌ها می‌پردازد.
· مقیاس‌پذیری:
قابلیت سیستم برای تحمل افزایش فشار بار در نرم‌افزار بدون کاهش عملکرد در دیگر بخش‌ها را اندازه‌گیری و ارزیابی می‌کند.
· قابلیت استفاده مجدد:
احتمال استفاده از یک بخش یا کامپوننت از سیستم در دیگر قسمت‌ها با ایجاد کم‌ترین تغییرات ممکن را نمایش می‌دهد. بهینه کردن دانه‌بندی، کاهش نسخه‌برداری بی‌رویه از کدها و جداسازی مسئولیت‌ها از دغدغه‌های اصلی این معیار کیفی است.
· قابلیت پشتیبانی:
قابلیت سیستم برای آماده کردن اطلاعات و ابزارها در جهت حل مشکلات پیش آمده برای نرم‌افزار است که از مخاطرات آن می‌توان به ضعف تحلیل عملکرد و فعالیت‌های سیستم، نبود ابزار جهت عیب‌یابی مانند ابزار تهیه snapshot و اصلاح خودکار بخش‌ها و نبود ابزار برای بررسی سلامت نرم‌افزار به صورت مقطعی در بازه‌ی زمانی مشخص اشاره کرد.
· قابلیت فعال بودن:
به کلیه زمانی که سیستم آماده به ارائه خدمات به کاربران است و میتوانیم به دریافت خدمات از آن اطمینان کنیم، می‌پردازد. از معیارهای سنجش آن می‌توان به تعداد دفعات از کار افتادن سیستم و زمان بین آن‌ها، میزان زمان توسعه محصول تا استقرار آن در محیط استفاده و زمان لازم برای به‌روزرسانی اجزای نرم‌افزار اشاره کرد.
هر نرم‌افزار، متناسب با هدف طراحی آن و استفاده‌ای که از آن می‌شود، تمرکز بر مفاهیم خاصی دارد. در برخی نرمافزارها، یکپارچگی و محرمانگی داده‌ها اهمیت دارد و در برخی دیگر، سرعت و کارایی اولویت بالاتری دارند. نرمافزارهای مبتنی بر بلاکچین نیز مانند دیگر نرمافزارها، مفاهیم مخصوص خود را دارند. در‌ادامه برخی از این مفاهیم را معرفی می‌کنیم و سپس الگوهای پرتکرار در این نرمافزارها را به همراه تاثیر آن‌ها به این مفاهیم و علت استفاده از آن‌ها مطرح می‌کنیم.
قراردادهای هوشمند
همانطور که گفته شد، قراردادهای هوشمند، کدها و برنامه‌های بر بستر بلاکچین هستند. به‌این‌ترتیب، طراحی آن‌ها از معماری و الگوهایی پیروی می‌کند. همچنین به‌علت محدودیت‌های شبکه بلاکچین، مباحثی چون حجم و سرعت اجرای این کدها بسیار اهمیت دارد. درواقع انواع پیچیدگی در کدها می‌تواند به صورت مستقیم تاثیر زیادی در هزینه نهایی ایجاد کند و از طرفی در عملکرد و مقیاس پذیری بلاک‌ها اختلال ایجاد کند. وابسته به هدف نرم‌افزار مبتنی بر بلاک چین، بخشی از آن ممکن است قراردادهای هوشمند باشد و با توجه به مواردی که مطرح شد، طراحی قراردادها، یکی از مفاهیم مورد توجه در این نرم‌افزار هاست.
مدیریت داده در بلاکچین
قطعا هر نرم‌افزاری با مجموعه داده‌ای سروکار دارد. طبیعتا نرمافزارهای مبتنی بر بلاکچین با داده‌های داخل شبکه در ارتباط هستند و در برخی از آن‌ها نیاز به ذخیره‌سازی داده‌ها در شبکه، برای استفاده از خصوصیت یکپارچگی و تغییر ناپذیری بلاکچین می‌باشد. ذخیره‌سازی داده به‌وسیله تراکنش ها امکان‌پذیر است و مشابه با قرارداده‌های هوشمند، حجم داده تاثیر مستقیم بر هزینه مورد نیاز برای تراکنش می‌گذارد. علاوه‌بر محدودیت حجم تراکنش در ذخیره داده، نرخ پردازش تراکنش‌ها در بلاکچین نیز تاثیر گذار است. با توجه به نیاز و وابستگی اکثر نرمافزارها به داده، الگوهای مدیریت آن از اهمیت ویژه‌ای برخوردار است و تاثیر مستقیمی بر معیارهای عملکرد، یکپارچگی و امنیت دارد.
وارد کردن اطلاعات از خارج شبکه
ماهیت برخی از داده‌ها، اعم از حجم، امنیت، مبدا و نرخ تغییرات آن‌ها، از ذخیره‌سازی دائم آن در شبکه جلوگیری می‌کند. همچنین برخی از داده‌ها از چندین منبع به‌دست می‌آیند. برای استفاده از این داده‌ها، به پروتکلی برای وارد کردن این داده و اطلاعات به شبکه نیاز است. نرخ بروزرسانی، میزان اعتماد به منتشر کننده‌ی داده و همچنین مبدا داده‌ی ورودی، پارامترهای انتخاب روش مناسب برای وارد کردن داده‌ها به شبکه بلاکچین هستند. برای مثال، برای تبادل استیبل کوین‌ها با ارز شبکه، نیاز به ارزش ارز شبکه در واحد کوین است که دائما در حال تغییر است و راهکاری برای وارد کردن این مقدار در فاصله زمانی کوتاه به شبکه نیاز است. از ویژگی‌های کیفی متاثر، می‌توان به دسترس‌پذیری، امنیت و قابلیت یکپارچگی اشاره کرد.
امنیت و حریم خصوصی
این پژوهش مرتبط با بلاکچین‌هایی هست که به‌صورت عمومی در دسترسی هستند. طبیعتا هر فرد می‌تواند به داده‌ها و تراکنش‌های ذخیره شده در شبکه دسترسی داشته‌باشد. در‌نتیجه، نرمافزارهای مبتنی بر بلاکچین، در‌صورت نیاز به حریم خصوصی، باید خود آن را ایجاد کنند. در برخی موارد داده‌ها در بلاکچین ذخیره می‌شوند و نیاز به ایجاد شرایطی که تنها گروه خاصی قابلیت دسترسی به آن را داشته باشند وجود دارد. همچنین پرداخت به صورت ناشناس و پنهان سازی دارایی از موارد استفاده از حریم خصوصی است و بستری برای ایجاد آن نیاز است.
امنیت داده‌ها و همچنین امنیت نرمافزارهای مبتنی بر بلاکچین دیگر مفهوم مورد توجه است. متناسب با هدف نرم‌افزار و همچنین ویژگی‌های آن، مواردی هستند که در امنیت آن تاثیر گذارند. برای مثال، برخی نرمافزارها نیاز به ایجاد تراکنش در شبکه از آدرس‌هایی غیر از قراردادهای هوشمند دارند که نیازمند کلید خصوصی یک آدرس برای خرج کردن دارایی‌های آن است. در‌صورت نشت پیدا کردن کلید خصوصی، فرد می‌تواند تراکنش دلخواه ایجاد کند و در روند نرم‌افزار اختلال ایجاد کند. همچنین دارایی‌های آدرس در خطر است و فرد می‌تواند به آدرس دلخواه خود منتقل کند. در‌نتیجه، حفظ کلید خصوصی به‌صورت امن از نیاز‌های امنیتی نرم‌افزار هست.
باید توجه داشت که برخی الگو‌ها قصد ایجاد امنیت و حریم خصوصی در نرمافزارهای مبتنی بر بلاکچین را دارند و در عین حال برخی الگو‌ها در نرمافزارهایی استفاده می‌شوند که قصد ایجاد امنیت و حریم خصوصی در سطح بلاکچین را دارند. در این پژوهش الگوهایی را بررسی می‌کنیم که در سطح بلاکچین این دو ویژگی را ایجاد می‌کنند. چراکه امنیت و حریم خصوصی در نرم‌افزار یه مفهوم کلی و مفصل است و مختص به هدف این پژوهش نمی‌شود. البته با معرفی الگوهای مرتبط با ایجاد حریم خصوصی، بحث استفاده از خدمات آن نرمافزارها را در دیگر نرمافزارهای مبتنی بر بلاک چین را نیز مطرح می‌کنیم.
نرمافزارهای متمرکز و غیر متمرکز
همانطور که در فصل گذشته مطرح شد، بلاکچین یک شبکه غیر‌متمرکز است. اما نرمافزارهای آن می‌توانند چنین نباشند. نرمافزارهای مبتنی بر بلاکچین در هر دو صورت متمرکز و غیر‌متمرکز وجود دارند و انتخاب معماری مناسب براساس هدف نرم‌افزار، تاثیر مستقیمی بر ویژگی‌های کیفی یکپارچگی، اطمینان، امنیت، مقیاس پذیری، پشتیبانی و قابلیت فعال بودن و تاثیر غیر مستقیمی بر کارایی، آزمایش پذیری، قابلیت نگه‌داری و استفاده مجدد دارد. اگرچه ایجاد چنین معماری پیچیدگی‌های مخصوص خود را دارد، اما عموما بهتر است در نرمافزارهایی که امکان آن وجود دارد استفاده شود. چراکه تاثیر مثبت و قابل توجهی بر کارایی، اطمینان و مقیاس پذیری دارد.
مهاجرت داده‌ها و پشتیبان‌گیری
دیگر مفهوم مورد توجه در بلاک چین و نرمافزارهای آن، بحث مهاجرت داده‌ها و پشتیبان‌گیری از آن‌هاست.پشتیبان‌گیری یکی از ارکان حفاظت از سیستم است و ایجاد شرایط مناسب برای آن، از مواردی هست که باید به آن توجه نمود. از طرف دیگر، بلاکچین‌ها و نرمافزارها دستخوش تغییر می‌شوند و در برخی موارد، برای افزایش کارایی، کاهش هزینه و حتی ارائه خدمات بیشتر، نرمافزارها از بلاک چینی به بلاکچین دیگر انتقال پیدا می‌کنند. متناسب با نرم‌افزار، داده‌های آن نیز ممکن است نیاز به مهاجرت داشته باشند و با‌توجه به خصوصیات بلاک چین، پیچیدگی‌هایی ایجاد می‌شود. برخی الگو‌ها برای سهولت مهاجرت بین شبکه‌ای و برخی در رابطه با پشتیبان‌گیری و نسخه‌برداری از داده‌های داخل شبکه ارائه می‌شوند.
تبادلات مالی و خرید در بلاکچین
یکی از ویژگی‌های اصلی بلاکچین فرآیند خرید در آن است که در ابتدا توجه بسیاری از سازمان‌ها را برای انجام تراکنش‌های مالی فرامرزی جلب کرد زیرا بدون نیاز به واسطه‌های بسیار مانند تراکنش‌های سنتی بانکی می‌تواند به راحتی و بدون محدودیت کاربران را به هدف خودشان برساند.
اگر بخواهیم معماری کلی فرآیند خرید را در بستر بلاکچین تشریح کنیم میتوانیم به ۳ عامل اصلی بپردازیم:
برای تبادل محصول و ارز بین این سه عامل، الگو‌ها و طراحی‌های مختلفی وجود دارد و متناسب هریک، ویژگی‌های کیفی مختلفی متاثر می‌شوند. برای مثال، در یک طراحی صادر کننده (issuer) توکنی را بر اساس قوانینی که از قبل تنظیم کرده منتشر می‌کند. سپس تعدادی توکن در اختیار خریدار (buyer) قرار می‌دهد و خریدار با استفاده از آن توکن‌ها، اقدام به خرید محصولاتی که از قبل برای خرید با آن توکن خاص تعیین شده‌اند، اقدام می‌کند. فروشنده (seller) محصول را به خریدار تحویل می‌دهد و سپس توکن را دریافت می‌کند. توکن استفاده‌شده باید از بین برود تا دیگر فرصت استفاده از آن به خریدار داده نشود.
به‌طور کلی، الگوهای نرم‌افزاری برای جلوگیری و حل مشکلات و پیچیدگی‌هایی هستند که در زمان توسعه نرم‌افزار ایجاد می‌شوند و می‌توان آن‌ها را به سه دسته کلی تقسیم کرد:
هریک از الگو‌ها، مستقل از سطح هدف، برخی ویژگی‌های کیفی را تحت تاثیر قرار می‌دهند. این تاثیرات می‌توانند مخرب و همچنین مفید باشد و انتخاب یک الگو باید متناسب با نیاز‌ها و اولویت مفاهیم مورد استفاده در نرم‌افزار باشد. برای مثال، یکی از مفاهیم مورد بررسی در نرم‌افزار های مبتنی بر بلاکچین، نحوه ذخیره‌سازی داده‌ها برروی آن است. برای برخورد با این مسئله، سه الگو رمزنگاری داده‌ها بر بلاکچین، استفاده از توکن برای مالکیت و ذخیره هش داده بر بلاکچین معرفی شده‌است. طبیعتا تاثیر هریک بر ویژگی‌های کیفی و بخصوص کارایی متفاوت است. در این مسئله، انتخاب الگو متاثر از حجم داده، میزان اهمیت آن و دفعات نیاز به آن است.
در ادامه الگوهای پرتکرار را معرفی می‌کنیم و علت و فواید استفاده از آن‌ها را به همراه مواردی که در دو بلاکچین اتریوم و ارگو استفاده شده‌است ذکر می‌کنیم.
قراردادهای هوشمند هم مانند دیگر ارکان نرم‌افزاری دچار تغییر و بروزرسانی می‌شوند اما در بلاک چین به دلیل ساختار غیر قابل تغییر، امکان تغییر یک قرارداد وجود ندارد و باید به صورت قرارداد جدید در آدرس جدیدی ایجاد شود. این عمل موجب اختلال در نرمافزارها و دیگر بخش‌های وابسته به این قرارداد می‌شود؛ چراکه این بخش‌ها از آدرس جدید خبردار نمی‌شوند. همچنین در‌صورت اطلاع از تغییر، ایجاد بروزرسانی پیچیدگی‌های خود را داراست.
برای حل این مشکل میتوانیم از رویکرد DNS برای نحوه اتصال به قراردادها استفاده کنیم، به این صورت که با استفاده از یک مرکز به نام contract registry به هر قرارداد با آدرس مورد نظر، نام و مشخصات در سطح انتزاع دلخواه الحاق می‌کنیم و سپس هرگونه درخواست را با استفاده از این مرکز ارتباطی پوشش می‌دهیم. در واقع در این روش توانسته‌ایم قراردادهای جدید را مدیریت کنیم و دسترس‌پذیری آن‌ها را نیز بهبود دهیم.
سرویس ENS در اتریوم یک نمونه است که ارتباط بین قرارداد هوشمند و منابع خارجی را به‌صورت اسم‌های ساده ایجاد می‌کند. در ارگو نیز، نرم‌افزار ErgoNames با این هدف ایجاد شده است و سرویس DNS تحت حمایت بلاکچین Ergo به صورت غیر متمرکز ایجاد کرده است.[4][5]
این الگو، جداسازی داده از منطق قرارداد هوشمند و ذخیره‌سازی آن در قرارداد جدا را مطرح می‌کند. مشابه با الگوی Contract Registry، قراردادها دستخوش تغییر می‌شوند و نسخه‌ی جدید لزوما قادر به دسترسی به داده‌های نسخه قدیمی نیست. از طرفی امکان استخراج داده‌ها از نسخه‌های قدیمی بسیار هزینه‌بر است و در برخی موارد مسائل امنیتی را به‌دنبال دارد. جداسازی داده از منطق قرارداد باعث می‌شود که دسترسی نسخه‌های جدید نیز به داده‌ها ثابت بماند و وابستگی و پیچیدگی میان داده و قرارداد کاهش یابد. از پروژه‌های در بستر اتریوم که از این الگو استفاده می‌کنند می‌توان colony را نام برد که از یک قرارداد هوشمند با ساختار داده عمومی برای ذخیره‌سازی داده‌های خود استفاده می‌کند.[6]
یک الگو در طراحی قراردادهای هوشمند، ایجاد یک قرارداد هوشمند برای ساخت قراردادهای جدید از یک قالب مشخص است. برخی قراردادها در بلاکچین از قالب مشخصی پیروی می‌کنند و برای ایجاد مورد مشابه، ایجاد قرارداد جدید از روی آن قالب لازم است. از جمله این قراردادها، می‌توان به ERC-20 در اتریوم، BEP20 در بایننس (Binance) و EIP-04 در ارگو اشاره کرد که استاندارد دارایی و توکن‌ها را بیان می‌کنند.[7][8]
ایجاد یک قرارداد و درخواست اضافه کردن آن به شبکه، یک عمل خارج از شبکه است و در این موارد تضمینی بر پیروی آن قرارداد از قالب مشخص وجود ندارد و در‌برخی موارد می‌تواند موجب مسائل امنیتی شود. این در شرایطی است که اگر قراردادی برای ساخت قرارداد هوشمند در سطح شبکه باشد، این مشکل حل می‌شود و نیاز به محاسبات خارج از شبکه نیز نیست. هرچند که در این الگو، محاسبات در سطح شبکه انجام می‌شود و هزینه را افزایش می‌دهد.
توابع و قراردادهای هوشمند به‌‌خودی‌خود اجرا نمی‌شوند و یک تراکنش و یا قرارداد دیگر عامل اجرای آن‌هاست. عموما برای اجرا و ایجاد این تراکنش‌ها، سرویس‌هایی خارج از شبکه قرار داده می‌شوند، اما اختلال در این سرویس‌ها، اختلال در روند اجرایی خواهد بود و می‌تواند کارایی را کاهش دهد. همچنین در برخی موارد، ارسال تراکنش و یا اجرای تابع به‌صورت ناشناس، نیازی برای ایجاد حریم خصوصی در سیستم است. در این الگو، جایزه‌ای برای کسی که تراکنش را بسازد قرار داده‌می‌شود. به این ترتیب هرکس می‌تواند سرویس خود را برای ایجاد این تراکنش‌ها قرار دهد و جایزه‌ی خود را هم دریافت کند. Alarm Clock، یک سرویس در اتریوم است که به کمک آن می‌توان یک تابع را برای اجرا در بلاکی خاص برنامه‌ریزی کرد و این سرویس برای اجرای آن توسط کاربران، جایزه‌ای در‌نظر گرفته است. در RosenBridge نیز، موجودیت Watcher و تراکنش ساخت EventTrigger به همین الگو دلالت دارند.[9][10]
یکی از الگوهای مرتبط با مدیریت داده‌ها در بلاک چین، رمزنگاری آن‌هاست. در این الگو، داده‌ها با الگوریتمی مشخص در خارج از شبکه رمزنگاری و داخل شبکه ذخیره می‌شوند. به‌این‌ترتیب، اگرچه که تراکنش‌ها به‌صورت عمومی در دسترسی هستند، اما داده‌های ذخیره شده در آن‌ها رمزنگاری شده‌است و تنها کسانی که کلید متناظر را داشته باشند می‌توانند به آن‌ها دسترسی پیدا کنند. با استفاده از این الگو، در عین استفاده از ویژگی‌های بلاکچین نظیر امنیت و تغییر ناپذیری، می‌توان حریم خصوصی و کنترل دسترسی به داده‌ها را ایجاد نمود. البته باید توجه داشت که امنیت داده‌ها وابسته به قدرت رمزنگاری آن‌هاست و استفاده از الگوریتم‌های ضعیف و روش‌های نادرست برای رمزنگاری داده‌ها، امنیت داده‌ها را تضمین نمی‌کند و موجب شکسته‌شدن و نشت پیدا‌کردن داده‌ها می‌شود.
برخی مخاطرات این روش:
یکی از استفاده کنندگان این الگو اوراکلایز (Oraclize) است. اوراکلایز به صورت یک قرارداد هوشمند در بستر بلاکچین اتریوم به کاربران و توسعه دهندگان نرم‌افزار اجازه می‌دهد از بیرون زنجیره به داده‌های رمزگذاری شده دسترسی داشته باشند و فقط هسته مرکزی اوراکلایز هست که کلید خصوصی را در اختیار دارد. همچنین MLGBlockchain از دیگر پروژه‌های استفاده کننده از این الگو است که پیش از اشتراک گذاری داده‌ها در بلاکچین، آن‌ها را رمز می‌کند.[11][12]
از توکن‌ها می‌توان برای نشانه‌گذاری و نمایندگی یک دارایی فیزیکی و یا یک سرویس استفاده کرد. استفاده از توکن به نمایندگی از یک دارایی محدود به بلاکچین نمی‌شود و از قدیم مورد استفاده بوده‌است. توکن‌های کازینو یک نمونه بارز است که نماینده واحد پول است و در کازینو با واحد پول تبادل می‌شود. استیبل کوین‌ها که در فصل گذشته معرفی شدند، نمونه‌ی بارز استفاده از این الگو هستند. از استیبل کوین‌های معادل یک دلار می‌توان USDC در شبکه اتریوم و SigmaUSD در شبکه ارگو را نام برد.[13][14]
این الگو، علاوه‌بر تسهیل تبادلات مالی، برای کنترل دسترسی نیز می‌تواند استفاده شود. برخی موارد، به‌خصوص زمانی که از الگوی Incentive Execution استفاده می‌شود، نیازی به داشتن کلید خاصی برای ایجاد تراکنش نیست. در این موارد، برای کنترل دسترسی و یا ایجاد شرایطی که تنها افراد مشخصی بتوانند تراکنش بزنند، می‌توان از توکن استفاده کرد. به‌این‌ترتیب تنها کسانی که دارای توکن خاصی باشند قادر به ایجاد آن تراکنش هستند و در سطح قرارداد هوشمند، دارا بودن آن توکن بررسی می‌شود. در پروژه RosenBridge، چند مورد دسترسی به کمک توکن ایجاد شده‌است. موجودیت Watcher با خرید توکن مشخصی، می‌تواند درخواست‌های انتقال را ضبط و گزارش کند. همچنین در بخش پاکسازی (cleanup service) این پروژه، تنها افراد مشخصی می‌توانند درخواستی را به عنوان تقلب نشانه‌گذاری کرده و اقدامات لازم را انجام دهند.[15][16][17]
برای استفاده از خصوصیات بلاکچین نظیر تغییرناپذیری، لزوما احتیاجی به ذخیره داده‌ها در بلاکچین نیست. این الگو، ذخیره‌سازی هش (Hash) داده‌ها را به منظور تضمین صداقت آن‌ها مطرح می‌کند. در مواردی که حجم داده‌ها بسیار زیاد است، امکان ذخیره‌سازی خود آن‌ها و یا مقدار رمز شده به دلیل هزینه زیاد وجود ندارد. اما می‌توان هش داده‌ها را ذخیره کرد و در زمان تایید کردن، هش را محاسبه و با هش ذخیره شده در بلاکچین مقایسه نمود. این الگو در بخش‌های مختلف نرم‌افزار قابل استفاده است. در پروژه RosenBridge، هش بخشی از داده‌ها محاسبه و با نام کامیتمنت (Commitment) در بلاکچین ذخیره می‌شود (علت این کار در محدوده این پژوهش نیست) و در ادامه از این مقدار برای تایید داده‌های مطرح شده استفاده می‌شود. در اتریوم، قرارداد هوشمند Chainy، ابزاری برای این الگو است که لینک دسترسی به یک داده خارج از شبکه را به همراه هش آن در شبکه ذخیره می‌کند.[18][19]
اوراکل‌ها، درگاه‌های ارتباطی شبکه بلاکچین با خارج شبکه هستند. این نرمافزارها، با نرخ مشخص، تراکنش‌هایی تولید می‌کنند که حاوی اطلاعات و داده‌های خارج از شبکه هستند. همانطور که در بخش قبل مطرح شد، برخی از داده‌ها به دلیل نرخ بروزرسانی و یا مبدا آن‌ها، باید به طریقی وارد شبکه بلاکچین شوند. برای مثال در شبکه ارگو، اوراکلی برای وارد کردن قیمت ارز ارگ به دلار وجود دارد که تقریبا هر 6 بلوک (معادل 12 دقیقه) قیمت جدید را وارد شبکه می‌کند. همچنین قیمت اتریوم به دلار به همراه مقدار ارائه شده توسط هر اوراکل در لینک زیر قابل مشاهده است.[20][21]
اوراکل‌ها در هر دو دسته متمرکز و غیر‌متمرکز وجود دارند. اوراکل‌های متمرکز عموما در مواردی استفاده می‌شوند که مبدا داده‌ی ورودی یکتا باشد و نیازی به چندین منتشر کننده نباشد، هرچند که استفاده از یک اوراکل باعث ایجاد یک نقطه شکست (single-point-of-failure) می‌شود.
در‌جهت حذف نقطه شکست و همچنین ایجاد اعتماد بیشتر به داده‌ی ورودی، اوراکل‌های غیر‌متمرکز مطرح شدند که چندین گره در اوراکل، داده را وارد شبکه می‌کنند و به کمک مکانیزم‌های رأی‌گیری، داده به‌صورت یکتا تولید می‌شود. برای مثال، قیمت استیبل کوین‌ها، میانگین مقادیر ارائه‌شده توسط گره‌های اوراکل است و تایید ارسال و دریافت یک محموله، وابسته به تایید حداقل تعدادی از گره‌های اوراکل است.
در این میان، برخی از نرمافزارها به ثبت وقایع بلاکچین در خارج از شبکه می‌پردازند که به آن‌ها اوراکل معکوس ReverseOracle گفته می‌شود. اوراکل‌های معکوس تقریبا جزئی از هر نرم‌افزار مبتنی بر بلاکچین هستند چراکه این نرمافزارها به‌گونه‌ای درگاه ارتباطی بین بلاکچین و شبکه خارجی هستند، اما عموما منظور از این اوراکل‌ها، مواردی تنها با هدف ارتباط داده و عموما غیر‌متمرکز است. از آن‌ها می‌توان identitii را نام برد که درگاه ارتباطی تبادلات مالی و ارسال اسناد بین بلاکچین و پروتکل SWIFT است.[22]
این الگو متناظر با الزام چند تایید است. برخی موارد، برای ارائه خدمات، انجام عمل مشخص و یا به ساده‌ترین روش ممکن، ارسال تراکنش، تایید چند فرد و موجودیت لازم است. این الگو برای حل این مسئله، مجموعه‌ای از n آدرس را تعریف می‌کند که تایید m عضو از آن برای تایید یک پرداخت لازم است. این الگو با نام Multi Signature هم شناخته می‌شود و بیانگر الزام تایید حداقل m نفر از n نفر برای ایجاد یک تراکنش است. اصولا به آدرس‌هایی که چنین تاییدی برای مصرف دارایی‌های آن‌ها لازم است، آدرس‌های مالتیسیگ گفته می‌شود و برخی از کیف‌پول‌ها قابلیت ایجاد آن‌ها را دارند.
این آدرس‌ها به کمک مبحث رمزنگاری و در سطح قراردادهای هوشمند پیاده‌سازی می‌شوند و جزئیات آن خارج از محدوده‌ی این پژوهش است. Guarda یک کیف‌پول اتریوم با قابلیت ایجاد آدرس مالتیسیگ است. همچنین Gnosis نیز مفهومی مشابه با این آدرس‌ها را ارائه می‌کند. در ارگو، Minotaur تنها کیف‌پولی است که چنین آدرس‌هایی را پشتیبانی می‌کند. از موارد استفاده از این آدرس‌ها، می‌توان پروژه‌ی RosenBridge را نام برد که آدرس لاک(Lock) در ارگو، یک آدرس مالتیسیگ است و موجودیت گارد‌ها افرادی هستند که تایید آن‌ها برای ایجاد تراکنش لازم است.[23][24][25][26]
الگوی دیگر برای حل این مشکل، Threshold Signature است که نباید این الگو اشتباه گرفته شود. Threshold Signature کاملا مشابه با مالتیسیگ، تایید m نفر از n نفر برای پرداخت لازم است، اما این موضوع به کمک مفاهیم رمزنگاری و بدون استفاده از قراردادهای هوشمند پیاده می‌شود و عملا یک آدرس است که برای پرداخت از آن، تجمیع m نفر لازم است. جزئیات و مفاهیم رمزنگاری این الگو از محدوده‌ی این پژوهش خارج است و برای مطالعه‌ی بیشتر، منابع [27][28][29] در دسترس هستند.
در الگوی قبل، آدرس‌هایی معرفی شدند که تایید چند نفر برای پرداخت از آن‌ها لازم بود. در شرایطی که اطمینان و امنیت به‌دلیل تایید چند نفر افزایش می‌یابد، ریسک به خطر افتادن دارایی‌ها نیز به دلیل وجود چند کلید و احتمال از دست رفتن آن‌ها نیز افزایش می‌یابد. برای حل این مشکل، دو کیف‌پول و آدرس ساخته می‌شوند. آدرس گرم (Hot) فقط مقدار لازم از دارایی را دارد و آدرس سرد (Cold) در‌بر دارد. از آدرس گرم برای تبادلات و تراکنش‌ها استفاده می‌شود و تنها زمانی که دارایی آن از حد مورد نیاز کمتر می‌شود، دارایی از آدرس سرد به آن منتقل می‌شود. به‌این‌ترتیب، در صورت از دست رفتن کلید، تنها دارایی‌های آدرس گرم در خطر است. کلید‌های متناظر با آدرس سرد به‌دلیل استفاده محدود از آن، امن‌تر ذخیره می‌شود و احتمال از دست رفتن آن کم است. MyEtherWallet یک نمونه کیف‌پول گرم است. در پروژه RosenBridge، آدرسی که موجودیت گارد‌ها برای پرداخت درخواست‌ها استفاده می‌کنند، آدرس گرم است و به‌صورت دوره‌ای، دارایی‌ها از آدرس گرم به آدرس سرد منتقل می‌شود و از جمع شدن آن‌ها در آدرس گرم جلوگیری می‌کند.
کلید اصلی و فرعی، یک الگو برای سهولت مدیریت چندین آدرس در جهت افزایش حریم خصوصی است. در برخی موارد، برای ایجاد حریم خصوصی، تنها یکبار استفاده از آدرس مجاز است و در این شرایط، صد‌ها و شاید هزاران آدرس باید ساخته شود. مدیریت این آدرس‌ها بسیار پیچیده می‌شود و امکان خطا و نشت و نقض امنیت وجود دارد. برای حل این مشکل، یک کلید اصلی ساخته می‌شود و از آن، برای ساخت کلید‌های فرعی و آدرس‌های یکبار مصرف استفاده می‌شود. لزوما این الگو برای استفاده یکبار مصرف نیست و تقریبا تمامی کیف‌پول‌ها، یک کلید اصلی و یا نمونیک (mnemonic) معادل آن را در اختیار کاربر قرار می‌دهند و برای آدرس‌های مورد استفاده، کلید‌های فرعی از کلید اصلی تولید می‌کنند. در ارگو، به‌غیر از کیف‌پول‌ها، پروژه میکسر (mixer) نیز از کلید اصلی و فرعی برای تولید آدرس‌های میکس استفاده می‌کند.[30]
برخی از دسترسی‌ها در دنیای ما به مدت زمان خاصی محدود می‌شوند. این موضوع در بلاکچین هم وجود دارد و در برخی موارد نیاز به پیاده‌سازی چنین دسترسی لازم است. برای مثال، زمانی که درخواستی برای مبادله صورت می‌گیرد، اگر یکی از طرفین مبادله از ادامه‌ی آن سرباز زند، طرف دیگر باید بتواند دارایی خود را برگرداند. در این مسئله، بازه‌ی زمانی برای مبادله باید تعیین گردد و طرفین اقدام مورد نیاز را در آن بازه انجام دهند.
پیاده‌سازی این دسترسی به کمک قرارداد هوشمند قابل انجام است و برای بیان زمان، از بلاک‌های شبکه استفاده می‌شود. طبیعتا زمان متناظر با تعداد بلاک برای هر بلاکچین متفاوت است. در اتریوم، تقریبا هر 12 ثانیه بلاک جدید تولید می‌شود و این زمان در ارگو تقریبا هر 2 دقیقه است. برای مثال، فرض کنید شبکه ارگو در بلاک 10000 است. برای محدود کردن خرج کردن یک دارایی برای یک ساعت آینده، کافیست شرطی گذاشته شود که اگر بلاک حال حاضر از 10030 کمتر بود، امکان پرداخت وجود دارد. این شرط به کمک قرارداد هوشمند گذاشته می‌شود. عموما در موارد تعویض و تبادل دارایی، شرطی برای لغو تبادل بعد از مدت زمان مشخص قرار داده‌می‌شود که مثالی برای این الگو است.
پایه‌ای ترین الگو مرتبط با امنیت در بلاکچین، صبر برای تاییدیه یک بلاک و یا تراکنش به تعداد کافی است. اگرچه بلاکچین تغییرناپذیر است، اما در‌حقیقت بلاکچین‌هایی که از اجتماع ناکاموتو (Nakamoto Consensus) استفاده می‌کنند، تغییرناپذیری را ارائه می‌کنند که با احتمال تعیین می‌شود. بلاک‌های بلاکچین، از اجتماع تایید گره‌های متفاوت بدست می‌آید. اگر 2 مجموعه گره همزمان بلاک جدید و متفاوتی را اضافه کنند، تنها یکی از آن‌ها معتبر است. تعیین انتخاب بلاک معتبر با اجتماع ناکاموتو انجام می‌گیرد و بلاکی که طولانی‌تر باشد معتبر است. در‌نتیجه، تراکنش‌هایی که در بلاک غیر معتبر هستند، در شبکه وجود نخواهند داشت و به اصطلاح فورک (Fork) می‌شوند.
با‌توجه به توضیحات بالا، برای اطمینان از تایید یک تراکنش و بلاک، بهتر است تا ثبت شدن چند بلاک بعد از آن منتظر ماند. با ثبت هر بلاک، احتمال فورک شدن بلاک‌های قبل به شدت کاهش می‌یابد، چراکه برای فورک کردن، هزینه محاسباتی بسیار زیادی لازم است. به تعداد بلاک ثبت شده بعد از یک بلاک، تعداد کانفیرمیشن (Confirmation) گفته می‌شود. در اتریوم، 10 کانفیرمیشن برای تایید یک بلاک پیشنهاد می‌شود.
این الگو یکی از پایه‌ای ترین الگو‌ها در ارتباط با بلاکچین است و تقریبا در هر نرم‌افزاری که با تایید و یا ارسال تراکنش سروکار دارد استفاده می‌شود. در کیف‌پول‌ها، بعد از ارسال تراکنش، تعداد کانفیرمیشن آن قابل مشاهده است و اکسچنج‌ها (Exchanges)، تعداد تایید مورد نیاز و تعداد کانفیرمیشن حال حاضر برای تایید سپرده نمایش می‌دهند.
به محض اینکه توکن استفاده می‌شود یعنی در زمانی که خریدار از توکن برای رسیدن به هدف خود استفاده نهایی را می‌کند همانطور که اشاره شد صادر کننده باید آن توکن را از بین ببرد و یا بلااستفاده کند. همین شرایط برای یک دید داده محور به بلاکچین هم قابل تشریح است مثلاً کلیه حالات یا قراردادهای هوشمندی که دیگر قابل استفاده نیستند باید به نحوی پردازش شوند که دیگر نشود از آن‌ها در بستر برنامه استفاده کرد.
برای اجرای سناریو گفته شده در بالا ۳ روش پر تکرار پیشنهاد می‌شود که بنا بر شرایط میتوانیم از هر کدام استفاده کنیم:
در حالت کلی با اجرای این روش‌ها یکپارچگی و امنیت نرم‌افزار افزایش می‌یابد اما از طرفی دیگر ممکن است این فرآیند‌ها هزینه‌های زیادی را برای محصول ایجاد کنند و قابلیت ردیابی هم بسیار کاهش می‌یابد؛ زیرا در پایان با از بین رفتن توکن‌ها، دیگر دریافت داده و اطلاعات از آن‌ها لزوما ممکن نیست.
دلایل مختلفی برای از بین بردن توکن‌ها می‌تواند وجود داشته باشد. یکی دیگر از آن دلایل، مهاجرت از یک بلاکچین به بلاکچین دیگر است. در این موارد توکن‌های تولید شده در بلاکچین مبدا باید از بین بروند. پروژه بایننس در زمان مهاجرت پایه اصلی پروژه خود از بیتکوین به اتریوم، درخواست از بین بردن توکن‌های موجود را از کاربران داشت.[31] در اتریوم، به‌صورت پیشفرض روشی برای از بین بردن توکن‌ها وجود ندارد و برای اینکار، توکن به آدرسی واریز می‌شود که توکن می‌تواند به آن وارد شود، ولی از آن خارج نمی‌شود. در ارگو این قابلیت وجود دارد و می‌توان توکن‌ها را در یک تراکنش از بین برد. البته امکان از بین بردن توکن اصلی شبکه، یعنی ارگ، وجود ندارد و برای چنین کاری باید مشابه با اتریوم، به آدرسی غیر قابل برداشت ارسال شود.
دو طرف خریدار و فروشنده باید در انجام فرآیند خرید محصول طوری عمل کنند که تا زمان تحویل نهایی محصول بر اساس سند توافق شده برای سرویس کاربران تراکنش تمام شود و توکن‌ها به صورت کامل منتقل شوند. در غیر این صورت باید تدابیر مشخصی انجام شود که در ادامه فرآیند آن‌ها توضیح داده‌می‌شود.
در مرحله اول، آن دسته از قوانین و شرایطی که توسط طرفین تعیین شده است، به صورت کامل ارائه می‌شود. سپس خریدار با در نظر گرفتن شرایط ذکر شده، اقدام به خرید و انتقال توکن‌ها به قرارداد هوشمند حاوی Escrow می‌کند. زمانی که Escrow از اتمام فرآیند‌ها بر اساس شرایط معین شده مطلع می‌شود، درستی آن‌ها را بررسی می‌کند. سپس در صورت صحت شرایط پیش آمده و تطبیق آن‌ها با قوانین، محصول را تحویل خریدار و توکن‌ها را به فروشنده می‌رساند. اما در صورتی که قوانین رعایت نشده باشد، عملیات را لغو کرده و توکن‌ها را به خریدار بر می‌گرداند.
برای اجرای این روش باید توجه کنیم که تمامی اطلاعات مربوط به تحویل کالا به خریدار و توکن به فروشنده به صورت شفاف و بدون ابهام به آن‌ها ارائه شود. مثلاً اگر ۱۲ روز کاری برای تحویل کالا نیاز است، باید خریدار از ساعت و تاریخ شروع و پایان آن مطلع شود. از طرفی اگر قرارداد هوشمند برای تکمیل مراحل تطبیق قوانین، به داده‌های دیگر سرویس‌های خارجی نیاز داشته باشد، می‌تواند با استفاده از الگوهایی که بر مبنای اوراکل هستند عمل کند. Kleros، یک پروتکل حل اختلاف نظر آنلاین است که با این الگو مشکل را در بستر بلاکچین حل می‌کند.[32]
آدرس پنهان، آدرسی است که دارایی‌های آن می‌تواند متعلق به افراد مختلفی باشد و در عین حال، مشخص نیست که چه کسی آن دارایی را دارد. آدرس‌های معمولی، هریک متناظر با یک زوج کلید عمومی و خصوصی هستند که دارنده‌ی آن، مالک دارایی‌های آن است. اما در آدرس پنهان، مالک یکتا وجود ندارد و متناسب با پارامترهای آن، هر فرد مالک بخشی از آن است و این مالکیت به کمک قراردادهای هوشمند و علوم رمزنگاری پیاده‌سازی می‌شود.
این الگو کاملا متناسب با حریم خصوصی است و در صورتی که شخص نخواهد میزان دارایی او مشخص باشد، می‌تواند از این آدرس‌ها استفاده کند. باید دقت شود که این آدرس‌ها به‌صورت استخر‌های دارایی هستند و هرچه افراد بیشتری از آن‌ها استفاده کنند، حریم خصوصی آن‌ها بیشتر می‌شود. نحوه ایجاد این آدرس در ارگو به چند روش در فروم توضیح داده شده‌است [33] و همچنین پیاده‌سازی و اضافه کردن آن به پروژه میکسر در‌حال انجام است .[34]
در مجموع همانطور که در بخش مقدمه نیز اشاره شد، در این پژوهش سعی شده تا نرمافزارهای مبتنی بر بلاکچین را به شکلی معمارانه مورد بررسی قرار دهیم. ابتدا در فصل ادبیات موضوع با اشاره به نکات اصلی موضوع تحقیق، تا سطح قابل قبولی در فضای مسئله وارد شدیم .سپس با استفاده از همان مبانی، الگوهای متداول در دنیای بلاکچین را از نگاه بهبود ویژگی‌های کیفی (Quality Attribute) مورد بررسی قرار دادیم و فناوری‌هایی که از آن‌ها استفاده کرده‌اند را به‌همراه ابزار‌هایی برای اجرای الگو‌ها معرفی کردیم.
از دستاوردهای کلی این پژوهش می‌توان به موارد زیر اشاره کرد:
همچنین برای درک بهتر برخی الگو‌ها، از پروژه RosenBridge استفاده شده است که یک پروژه متن باز است و توضیحات و سند‌های آن به‌صورت عمومی در دسترس است. معرفی این پروژه مرتبط با این پژوهش نیست اما آشنایی با آن برای درک مثال‌های این پژوهش لازم است، ویدئو‌ی [35] هدف پروژه را به‌همراه روند آن بیان کرده است.
--این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
--امیدواریم این مطلب برای شما مفید بوده باشه.
[1] https://aws.amazon.com/what-is/blockchain
[2] https://tether.to/en
[3] https://gold.tether.to
[4] https://ens.domains
[5] https://github.com/ergonames
[6] https://colony.io/
[7] https://ethereum.org/en/developers/docs/standards/tokens/erc-20
[8] https://github.com/ergoplatform/eips/blob/master/eip-0004.md
[9] https://www.ethereum-alarm-clock.com/
[10] https://github.com/rosen-bridge/contract#3--event-trigger-creation
[11] https://docs.provable.xyz/#ethereum-advanced-topics-encrypted-queries
[12] https://mlgblockchain.com/crypto-signature.html
[13] https://www.circle.com/en/usdc
[14] https://sigmausd.io
[15] https://github.com/rosen-bridge
[16] https://github.com/rosen-bridge/contract#1--get-watcher-permit
[17] https://github.com/rosen-bridge/contract#3--rsn-slash
[18] https://github.com/rosen-bridge/contract#2--event-commitment-creation
[19] https://chainy.info
[20] https://explorer.ergoplatform.com/en/oracle-pool-state/ergusd
[21] https://data.chain.link/ethereum/mainnet/crypto-usd/eth-usd
[22] https://identitii.com/
[23] https://guarda.com/multisignature-wallet/
[24] https://gnosis-safe.io/
[25] https://github.com/minotaur-ergo/minotaur-wallet
[26]https://github.com/rosen-bridge/contract#contracts
[27] https://link.springer.com/referenceworkentry/10.1007/0-387-23483-7_429
[28] https://academy.binance.com/en/articles/threshold-signatures-explained
[29] https://github.com/bnb-chain/tss-lib
[30] https://github.com/ergoMixer/ergoMixBack
[31] https://community.binance.org/topic/44/binance-chain-mainnet-swap
[32] https://kleros.io/en/
[33] https://www.ergoforum.org/t/stealth-address-contract/255#:~:text=A%20stealth%20address%20preserves%20recipient,%2Dtime%20address%20from%20it
[34] https://github.com/aragogi/Stealth-doc
[35] https://www.youtube.com/watch?v=Xsiy-yPJQ6w
[36] Nicolas Six, Nicolas Herbaut, Camille Salinesi, Blockchain software patterns for the design of decentralized applications: A systematic literature review, Blockchain: Research and Applications, Volume 3, Issue 2, 2022, 100061, ISSN 2096-7209, https://doi.org/10.1016/j.bcra.2022.100061.
[37] https://research.csiro.au
