مدل تراکنش اتریوم

در این مطلب با مدل تراکنش اتریوم، حساب‌‌ها و UTXOها، نحوه ذخیره داده و مزایای UTXOs آشنا خواهید شد.

0 94

پروتکل در سطح بلاک چین‌‌

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

حساب‌‌ها و غیر UTXOها

بیت کوین، همراه با بسیاری از مشتقاتش، داده‌‌های بالانس یا تراز کاربران را در یک ساختار مبتنی بر خروجی‌‌های تراکنش مصرف‌‌نشده (UTXOها) ذخیره می‌‌کند: کل حالت سیستم از مجموعه‌‌ای از “خروجی‌‌های مصرف‌‌نشده” (مثلا “کوین‌‌ها”) تشکیل شده و هر کوین یک مالک و یک ارزش دارد. هر تراکنش یک یا چند کوین را مصرف می‌‌کند و با توجه به محدودیت‌‌های اعتباری، یک یا چند کوین جدید می‌‌سازد. این محدودیت‌‌ها عبارتند از:

1- هر ورودی ارجاع‌‌داده‌‌شده باید معتبر و مصرف‌‌نشده باشد

2- برای هر ورودی، امضای موجود در تراکنش باید با امضای مالکِ ورودی مطابقت داشته باشد

3- مجموع ارزش ورودی‌‌ها باید مساوی یا بیشتر از مجموع ارزش خروجی‌‌ها باشد

بالانس (Balance) یک کاربر در سیستم برابر است با ارزش کلی مجموعه کوین‌‌هایی که کاربر برای آن‌‌ها کلید خصوصی ساخته است تا بتواند با آن‌‌ها امضای معتبر تولید کند.

مدل تراکنش اتریوم

عکس از https://bitcoin.org/en/developer-guide

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

مزایای UTXOها:

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

2- الگوهای مقیاس پذیری احتمالی: UTXOها از لحاظ تئوری، سازگار با الگوهای مقیاس پذیری مهم هستند؛ به طوری که می‌‌توانیم با تکیه بر مالک بعضی از کوین‌‌ها، اثبات مالکیت مرکل (Merkle) را حفظ کنیم و حتی اگر همه از جمله خود مالک نیز بخواهد آن داده را حذف کند، تنها کسی که آسیب می‌‌بیند مالک است. در یک الگوی حساب، همه سهم درخت مرکلِ متناظر با هر حساب را از دست می‌‌دهند و این باعث می‌‌شود که پردازش پیام‌‌هایی که حساب را از هر جهت تحت تاثیر قرار می‌‌دهد، مثل فرستادن آن‌‌ها به حساب، غیر ممکن شود. با این وجود، الگوهای مقیاس پذیری غیر وابسته به UTXOها هنوز وجود دارند. (فهم این جمله کمی سخت است.)

مزایای حساب‌‌ها:

1- ذخیره فضای بزرگ: برای مثال، اگر یک حساب کمتر از 5 UTXO داشته باشد، انتقال از یک مدل UTXO به یک مدل حساب، فضای مورد نیاز را از 300 بایت به 30 بایت کاهش می‌‌دهد. در واقعیت، ذخیره‌‌ها اینقدر عظیم نیستند زیرا حساب‌‌ها در درخت پاتریشیا ذخیره می‌‌شوند، ولی به هر صورت آنها بزرگ هستند. به علاوه، تراکنش‌‌ها می‌‌توانند کوچکتر باشند (مثلا 100 بایت در اتریوم و یا بین 200 تا 250 بایت در بیت کوین) زیرا هر تراکنش باید تنها یک مرجع و یک امضا داشته باشد تا فقط یک خروجی بسازد.

2- قابلیت تعویض (fungibility) بیشتر: به دلیل اینکه هیچ مفهومی در سطح بلاک چین‌‌ در مورد منبع یک مجموعه‌‌ی خاص از کوین‌‌ها وجود ندارد، تاسیس یک طرح لیست قرمز/ لیست سیاه برای ترسیم یک مرز مشخص بین کوین‌‌ها براساس مبداشان، هم از بعد فنی و هم از بعد قانونی، خیلی عملی نیست.

3- سادگی: فهم کدها آسان‌‌تر است، به خصوص وقتی یک خط کد پیچیده به کدها اضافه می‌‌شود. ممکن است اپلیکیشن غیر متمرکز دلخواهی را در الگوی UTXO وارد کنند. مشخصا این خطوط قابلیت این را دارند که مشخص کنند که چه نوعی از UTXO می‌‌تواند یک نوع مشخص از UTXO را مصرف کند و آن‌‌ها را طوری مقید می‌‌کند که هر مصرف، باید اثبات‌‌های تغییر-در-حالت-ریشه‌‌ای-اپلیکیشن از درخت مرکل را شامل شود. چنین الگویی بسیار پیچیده‌‌تر و بدریخت‌‌تر از الگوی حساب‌‌هاست.

4- مرجع‌‌دهی تمام وقت کلاینت لایت (light client): مشتری‌‌های لایت در همه‌‌ی نقاط قابلیت دسترسی به همه‌‌ی داده‌‌های مربوط به یک حساب را دارند. آن‌‌ها این کار را از طریق اسکن کردن حالت درخت در یک جهت مشخص انجام می‌‌دهند. در یک الگوی UTXO، مراجع نسبت به هر تراکنش تغییر می‌‌کنند و این برای اپلیکیشن‌‌های غیر متمرکز بلندمدت که از این مکانیزم UTXهای-حالت-ریشه‌‌ای استفاده می‌‌کنند، مشکل‌‌ساز است.

به دلیل سروکار داشتنمان با اپلیکیشن‌‌های غیر متمرکزی که کدها و حالت دلخواهی را شامل می‌‌شوند، به این نتیجه رسیدیم که مزایای حساب‌‌ها، بسیار بیش‌‌تر از سایر روش‌‌ها است. به علاوه، طبق قانون ” We Have No Features “، اگر مردم واقعا نگران حریم خصوصی خود هستند، باید از طریق پروتکل‌‌های پاکت-داده‌‌های-امضاشده (signed-data-packet) که درون قراردادها وجود دارند، میکسر‌‌ها و کوین‌‌جوین‌‌ها را بسازند.

یکی از ضعف‌‌های الگوی حساب‌‌ها این است که برای جلوگیری از حمله‌‌های replay ، هر تراکنش باید یک “nonce” داشته باشد و حساب‌‌ها، به‌‌کارگیریِ این ” nonce “ها را ردیابی می‌‌کنند و تنها تراکنشی که پس از به‌‌کارگیری آخرین nonce، nonce برابر با 1 داشته باشد را می‌‌پذیرند. این یعنی حتی حساب‌‌های پیش-از-این-استفاده-نشده نیز از حالت حساب حذف نمی‌‌شوند. یک راه‌‌کار ساده این است که تراکنش‌‌هایی برای ذخیره‌‌ی شماره بلوک‌‌ها داشته باشیم، پس از یک دوره‌‌ی زمانی، آن‌‌ها را غیر قابل بازپخش کنیم و هر nonce را در آغاز هر دوره، مجددا تنظیم کنیم. ماینرها یا دیگر کاربران باید حساب‌‌های استفاده‌‌نشده را برای حذف کردن از روی حالت، “پینگ” کنند و این کار هم بسیار گران تمام می‌‌شود زیرا باید یک سوئیپ کامل (full sweep) را به عنوان جزئی از پروتکل بلاک چین‌‌ انجام داد. ما فقط برای سرعت بخشیدن به توسعه‌‌ 1/0 به 1/1 این مکانیزم را انتخاب نکردیم، در 1.1 و بعد از آن نیز از این مکانیزم استفاده خواهد شد.

سوالات خود را با ما درمیان بگذارید.

شاید از این مطالب هم خوشتان بیاید.

ارسال پاسخ

آدرس ایمیل شما منتشر نخواهد شد.