نحوه ارسال تراکنش‌‌ها در اتریوم

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

0 96

نحوه ارسال تراکنش‌‌ها در اتریوم:

موضوعات مطرح شده در اینجا که زمینه‌‌ی گسترده‌‌ای را در برمی‌‌گیرند اینها هستند:

مقدمه

اتریوم یک سیستم مبتنی‌‌بر حساب کاربری یا اکانت است. اکانت‌‌ها بر دو دسته‌‌ هستند؛ اکانت‌‌های با مالکیت بیرونی (Externally Owned Account) و اکانت‌‌های قراردادی (Contract account). همه‌‌ی اکانت‌‌ها از هر دو دسته، دارای یک آدرس، یک نانس (nonce) و یک موجودی یا مانده حساب (balance) هستند، ولی اکانت‌‌های قراردادی افزون بر این موارد دارای کد تغییرناپذیر و ذخیره‌‌‌‌سازی نیز می‌‌باشند. هر تراکنش دارای فیلدهای زیر می‌‌باشد:

  • نانس (nonce): شمارنده‌‌ تعداد تراکنش‌‌های صادر شده است و با 0 آغاز می‌‌شود.
  • قیمت  gasPrice) Gas): قیمتی است که مشخص می‌‌کند هزینه‌‌ هر تراکنش چند اتر است.
  • حد  gasLimit) Gas) : ماکزیمم مقدار Gas که امکان پرداخت آن برای تراکنش وجود دارد.
  • اکانتی که تراکنش به آن ارسال می‌‌کند. اگر این فیلد خالی باشد، تراکنش یک قرارداد به وجود می‌‌آورد.
  • ارزش (value): مقدار اتری که با تراکنش فرستاده می‌‌شود.
  • دیتا: می‌‌تواند پیام دلخواه یا فراخواندن یک قرارداد یا کدی برای ایجاد یک قرارداد باشد.

نکته‌‌ی مهم این است که فیلد «از سوی» وجود ندارد و مبدا تراکنش به وسیله‌‌ی جفت کلیدهای عمومی – خصوصی مشخص می‌‌شود. این کلیدها پس از اجرای انکود RLP مناسب برای امضاء کردن هش تراکنش به کار می‌‌روند.

مصرف Gas و توکن Gas

بلاک چین را از یک نظر می‌‌توان نوعی دیتابیس مشترک دانست. هرگونه خواندن و یا نوشتن هزینه‌‌ای دارد که برحسب Gas است و صرف جلوگیری از حملات اسپم می‌‌شود. به طور مشخص در هر گام محاسباتی برای پیشگیری از حملات بازایستایی (halting attack) می‌‌بایست مقداری Gas صرف شود. این هزینه برحسب آپکد (opcode) در رساله زرد (yellow paper) مشخص گردیده است. اینکه هزینه‌‌‌‌ی هر آپکد (یا کد عملیاتی) باید چقدر باشد، همچنان محل بحث است و گروهی بحث به وجود آوردن فضای ذخیره‌‌ی کرایه‌‌ای و حتی قیمت‌‌گذاری دینامیک Gas / آپکد را مطرح می‌‌کنند.

حالت نگارش می‌‌تواند بسیار گران تمام شود. به وجود آوردن یک اسلات ذخیره‌‌ی غیرصفر و جدید 20,000 Gas هزینه دارد. رقمی که نزدیک به هزینه‌‌ی 21,000 پایه تراکنش است و برای یک جابه‌‌جایی ساده‌‌ی اتر باید آن را پرداخت کرد (محل آن در فیلد دیتای بالای فضای خالی در سمت چپ است). به عنوان راهکاری برای پیشگیری از افزایش حجم بی‌‌رویه‌‌ی بلاک چین، پروتکل اتریوم در ازای پاک کردن اندوخته‌‌های قدیمی که دیگر نیازی به آن‌‌ها نیست، مقدار 10,000 Gas را بازمی‌‌گرداند.

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

چندی پیش در شماری از صرافی‌‌ها که حد  (gasLimit ) Gas) را به درستی تنظیم نکرده بودند یک آسیب‌‌پذیری پیدا شد. حمله به این آسیب‌‌پذیری ساده است. ابتدا حمله کننده به صرافی یک درخواست برداشت می‌‌دهد، سپس این مبلغ را به قراردادی که از پیش ایجاد کرده می‌‌فرستد. این قرارداد دارای یک تابع بازگشتی (fallback ) است که توکن‌‌های Gas جدید به وجود می‌‌آورد.

تراکنش‌‌های متا

تراکنش‌‌ متا یا متاتراکنش (Metatransaction) یک الگوی ارسال هستند که در آن‌‌ها فرستنده می‌‌تواند یک تراکنش معتبر اتریوم را امضاء کرده و آن را به بیرون از زنجیره ارسال کند. مقصد این تراکنش یک رله (میانجی) است که هزینه‌‌‌‌‌‌‌‌‌‌‌‌‌‌ Gas آن را می‌‌پردازد و این تراکنش امضاء شده را در شبکه پخش می‌‌کند.

نحوه ارسال تراکنش‌‌ها در اتریوم

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

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

معمولا مقصد تراکنش‌‌ها یک قرارداد هوشمند است. این قرارداد هوشمند می‌‌تواند تشخیص دهد که امضاء کننده‌‌ی تراکنش ورودی همان آغاز تراکنش نیست. فرستنده‌‌ی پیام (msg.sender) آدرس رله‌‌هایی را باز می‌‌گرداند که احتمالا مجوز لازم برای اقدام کردن از سوی امضاء کنندگان ندارند. از این فرستنده پیام در این سناریو چندان کارآمد نیست. به جای آن، متاتراکنش‌‌ها از شیوه‌‌ی اعتبارسنجی امضای درون زنجیره‌‌ای (با ecrecover) استفاده کرده و بررسی می‌‌کنند که آیا امضاء کننده برای اقدامی که تراکنش می‌‌خواهد انجام دهد در لیست سفید قرار دارد یا خیر.

ارسال‌‌های زیردریایی

(نباید با سواپ‌‌های زیردریایی اشتباه گرفته شود)

هدف از ارسال‌‌های زیردریایی (Submarine sends) بهره‌‌گیری از ویژگی محرمانگی است؛ آن هم به میزان زیاد. ارسال‌‌های زیردریایی به جای اینکه میزان تراکنش را پنهان کنند، خود تراکنش را پنهان می‌‌سازند. البته تراکنشی که برای همیشه پنهان بماند به درد کسی نمی‌‌خورد. به همین خاطر ارسال‌‌های زیردریایی کاری می‌‌کنند که در آینده هرگاه فرستنده‌‌ بخواهد به تراکنش دسترسی پیدا کنند، بتواند این کار را انجام دهد.

نحوه ارسال تراکنش‌‌ها در اتریوم

به کمک ارسال زیردریایی، تراکنش کاربر از دید ماینرها پنهان می‌‌ماند

تراکنش کامیت یا سپارش (commit transaction) دارای یک سپارش کریپتوگرافیکی (cryptographic commit) است که دیتای ویژه‌‌ی کارکرد مورد نظر کاربر را به قرارداد هوشمند می‌‌دهد. این سپارش کریپتو همچنین تمامی اترها یا توکن‌‌های موجود را در آدرس زیردریایی قفل می‌‌کند. این آدرس را نمی‌‌توان از یک آدرس تازه تشخیص داد. هر مقدار ارزشی که در آدرس زیردریایی قفل شده باشد تنها می‌‌تواند به وسیله‌‌ی قرارداد هوشمند آزاد گردد. ما با افزودن ارزش پولی به تراکنش سپارش (که در صورت آشکار نشدن از سوی کاربر می‌‌سوزد) می‌‌توانیم انگیزه‌‌های نیرومندی ایجاد کنیم تا کاربران بدخواه به دنبال آشکار کردن گزینشی سپارش‌‌ها نروند. پس از آنکه یک تراکنش سپارش به درستی در بلاک چین قرار گرفت، کاربر می‌‌تواند سپارش خود را برای قرارداد هوشمند آشکار کند و در نتیجه قرارداد هوشمند منطق کاربردی خواسته شده‌‌ی او را به اجرا درآورد.

نمونه‌‌سازی خلاف واقع

واژه‌‌ی «خلاف واقع» (Counterfactual) ریشه در یکی از مفاهیم فلسفه و منطق دارد. یک گزاره‌‌ خلاف واقع در حقیقت زنجیره‌‌ معتبری از استدلال‌‌ها است که به عمد با فرض و نتیجه‌‌گیری نادرست انجام می‌‌شوند. در گزاره‌‌ی خلاف واقع، فرض مبنا نادرست است ولی ادعای مطرح شده به طور کلی درست است، زیرا اگر فرض درست بود آنگاه نتیجه هم باید درست می‌‌بود (با فرض نادرست به نتیجه‌‌ نادرست رسیدن درست است). این منطق نه تنها برای شکل کنونی زنجیره برای قراردادهای اجرا شده، بلکه در زمینه تراکنش‌‌های بلاک چینی درباره شکل زنجیره نیز به کار گرفته می‌‌شود.

نحوه ارسال تراکنش‌‌ها در اتریوم

به تازگی، الگوی گرفتن آدرس یک قرارداد پیش از پیاده کردن آن را «نمونه‌‌سازی خلاف واقع» (counterfactual instantiation) می‌‌نامند. این روش به وسیله‌‌ی L4 و در رساله‌‌ی آن‌‌ها به نام «کانال‌‌های حالت خلاف واقع» (Counterfactual State Channels) شناخته شد.

در حال حاضر، آدرس‌‌های قرارداد جدید به وسیله‌‌ی آپکد CREATE و براساس آدرس سازنده (فرستنده) و شمار تراکنش‌‌های ارسال شده از سوی سازنده (نانس) تولید می‌‌شود و قطعیت دارند. فرستنده و نانس با RLP انکود می‌‌شوند و سپس با Keccak256 هش‌‌دار می‌‌شوند تا آدرس تازه‌‌ای ایجاد گردد.

آپکد کوچکCREATE2  این رویه را بهبود می‌‌دهد، زیرا باعث می‌‌شود بتوانیم با آدرس‌‌هایی برهم‌‌‌‌کنش (بده‌‌ بستان) انجام دهیم که هنوز در زنجیره وجود ندارند. با اینکه این آدرس‌‌ها در زنجیره نیستند می‌‌توانیم مطمئن باشیم بالاخره کدهایی که به وسیله‌‌ی یک تکه کد اینیت (init) به وجود آمده‌‌اند در آن‌‌ها قرار خواهند گرفت. CREATE2 به جای رویه‌‌ی معمول به کارگیری «هش فرستنده و نانس» به عنوان آدرس شکل‌‌گیری قرارداد، از 0xff ++ address ++ salt ++ keccak256(init_code)))[12:]) keccak256) استفاده می‌‌کند.

این روش به طور مشخص برای موارد به کارگیری حالت – کانال (state-channel) اهمیت دارد که دارای برهم‌‌کنش‌‌های خلاف واقع با قراردادها هستند. به کمک این روش می‌‌توان زنجیره ریشه اتریوم را به عنوان لایه مخالفت (dispute layer) استفاده کرد، بدون اینکه هزینه‌‌ پیاده کردن قرارداد وجود داشته باشد. به همین صورت می‌‌توان آن را در شرایطی به کار برد که یک آدرس تازه با کارکرد شناخته شده تولید شده‌‌ است؛ مانند آدرس بازپرداخت وام.

تراکنش‌‌های تایید صفر

نحوه ارسال تراکنش‌‌ها در اتریوم

تراکنش‌‌های تایید صفر (Zero Confirmation Transactions) زمینه‌‌ی پژوهشی جالب و ثابت نشده‌‌ای هستند که از بیت کوین‌‌ کش ریشه می‌‌گیرد؛ شبکه‌‌ای که در آن زمان‌‌های بلوک برای UX مشکل‌‌سازتر از اتریوم است. در تراکنش تایید صفر، فرستنده یک وجه ضمانت می‌‌دهد، به گونه‌‌ای که در صورت پرداخت دوبل، این وجه از بین می‌‌رود. در بیت کوین‌‌ کش، پرداخت‌‌های دوبل با استفاده‌‌ی دوباره از ورودی‌‌هایUTXO پدیدار گردید. هرکسی (به فرض ماینر بودن) می‌‌توانست دو تراکنش ارائه دهد و وجه ضمانت مربوطه را بگیرد.

در شبکه‌‌ی مبتنی‌‌بر اکانت اتریوم، به جای UTXO بررسی می‌‌کنیم که کدام فرستنده از یک نانس دوبار استفاده کرده است. هر قرارداد همراه با یک تابع «گزارش پرداخت دوبل» (reportDoubleSpen) پیاده می‌‌شود. این تابع دو تراکنش امضاء شده‌‌ی مکمل هم را می‌‌گیرد، فرستنده‌‌ها و نانس‌‌هایشان را چک می‌‌کند و اگر همخوانی داشته باشند، مبلغ سپرده یا وجه ضمانت را به گزارش دهنده (کسی که تابع را فراخوانی کرده) پاداش می‌‌دهد. منطق کار به این صورت است که اگر وجه ضمانت به اندازه‌‌ی کافی باشد، این رویه فرستندگان تراکنش را از تقلب (پرداخت دوبل) بازمی‌‌دارد، زیرا چنین کاری با ریسک از دست دادن سپرده‌‌ آن‌‌ها همراه است. باور موجود این است که چنین تراکنشی بیشتر برای پرداخت‌‌های یکباره و با ارزش اندک مناسب است زیرا در آن امکان انجام حملات گوناگون وجود دارد.

جابه‌‌جایی‌‌های دسته‌‌ای

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

نحوه ارسال تراکنش‌‌ها در اتریوم

این ویژگی جابه‌‌جایی دسته‌‌ای (batched transfer) را می‌‌توان در لایم‌‌چین (Limechain) دید. جایی که در به کمک اصل تایید اعتبار درون زنجیره‌‌ای امضا (که از متاتراکنش گرفته شد)، تابع انجام کار با توکن یا ()doSomethingForTokens  درخواست تاییدapprove()  را برمی‌‌گرداند؛ به این ترتیب نااتمی بودن تایید ()approve در ERC-20 و الگوی ()transferFrom از بین می‌‌رود.

پرداخت‌‌های مبتنی‌‌بر اس‌‌ام‌‌اس

کوین تکست (CoinText ) را می‌‌توان بهترین سرویس اس‌‌ام‌‌اسی پرداخت رمز ارز دانست که بر تراکنش‌‌های بیت کوین‌‌ کش تمرکز دارد. روش پرداخت این سرویس به ویژه برای دستگاه‌‌هایی که در اقتصادهای ضعیف‌‌تر با مشکل منابع روبه‌‌رو هستند بسیار سودمند است. Eth2 همانند این تکنولوژی را در پلتفرم اتریوم ساخته و پیاده نموده است. این تکنولوژی با کیف پول‌‌های اپلیکیشنی اتریوم مانند کیف پول تراست (Trust) سازگاری دارد.

نحوه ارسال تراکنش‌‌ها در اتریوم

eth2.io ، یک شیوه‌‌ی پرداخت کریپتوکارنسی برمبنای اس‌‌ام‌‌اس

در این شیوه‌‌ به طور مشخص از یک قرارداد هوشمند اسکرو (escrow) استفاده می‌‌شود. فرستنده یک جفت کلید عمومی – خصوصی ترانزیتی (transit) می‌‌سازد، مقداری اتر را در قرارداد هوشمند اسکرو سپرده می‌‌گذارد و جفت کلید ترانزیتی را با این سپرده پیوند می‌‌دهد. کلید خصوصی همراه یک کلید سیستمی که به صورت رندوم ساخته شده رمزنویسی می‌‌شود و این نوشته‌‌ی رمزنویسی شده (به وسیله‌‌ی ایمیل، اس‌‌ام‌‌اس یا واتس‌‌اپ) به سرور مرکزی تایید کننده ارسال می‌‌گردد. برای برداشت از سپرده، هنگامی که شماره تلفن گیرنده تایید شد، سرور تایید کننده نوشته‌‌ رمزنویسی شده را برای گیرنده می‌‌فرستد. گیرنده آن را رمزگشایی کرده و یک پیام برداشت را امضاء می‌‌نماید. قرارداد هوشمند اسکرو تایید می‌‌کند که این پیام به وسیله کلید خصوصی ترانزیتی امضاء شده است.

برای تایید تلفن و جابه‌‌جایی کی‌‌استور (keystore) از یک سرور متمرکز استفاده می‌‌شود، ولی سرور Eth2 کنترلی روی اتر قفل شده در قرارداد هوشمند اسکرو ندارد. اگر این سرور از دست برود، تراکنش‌‌ها ناکام می‌‌مانند و اتر در حساب اسکرو باقی می‌‌ماند. برای پس گرفتن اتر، فرستنده می‌‌تواند با یک درخواست به قرارداد هوشمند اسکرو کار جابه‌‌جایی را کنسل کند.

پرداخت‌‌های آبونمانی

پرداخت‌‌های مبتنی‌‌بر آبونمان انصرافی (Opt-out subscription) شیوه‌‌ رایج سرویس‌‌های جهان در Web2.0 است. اسپاتیفای (Spotify)، نتفلیکس (Netflix)، هداسپیس (Headspace)، تیندر (Tinder) و دیگر کمپانی‌‌های بزرگ همگی مدل‌‌های درآمد خود را برمبنای پرداخت‌‌های آبونمانی قرار داده‌‌اند.

نحوه ارسال تراکنش‌‌ها در اتریوم

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

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

درخواست‌‌های ایجاد شده به کمک اوراکل

روش نامعمول دیگری که می‌‌توان برای ارسال تراکنش نام برد، به کارگیری یک سرویس اوراکل (oracle) است. سرویس‌‌هایی مانند اوراکلایز (Oraclize ) مصرف Gas را کاهش می‌‌دهند ولی در عوض باعث بیشتر شدن تمرکز می‌‌گردند.

نحوه ارسال تراکنش‌‌ها در اتریوم

استفاده از اوراکلایز مصرف Gas را برای یک فراخوانی تابع ثابت کاهش می‌‌دهد

این روش زمانی کار می‌‌کند که نیاز به فراخوانی تابع ثابت (constant function call) غیرتراکنشی باشد. تابع را می‌‌توان از یک گره سینک شده با شبکه اتریوم فراخواند، با استفاده از theeth_call JSON-RPC. برای جستجو از ()oraclize_query  اوراکلایز استفاده می‌‌شود که پس از به کارگیری اوراکلایز در قرارداد در دسترس خواهد بود. افزون بر این، باید a __callback به صورت bytes32 queryId, string results در درون قرارداد تعریف شود زیرا در هنگام جستجو این شیوه درخواست می‌‌گردد و نتایج را همراه خود می‌‌آورد. رسیدن به این نتایج حالت ثابت با استفاده از فراخوانی‌‌های مستقیم درون زنجیره‌‌ای بسیار پرهزینه‌‌تر از فراخوانی با اوراکلایز است.

چندارسالی با آدرس‌‌های یکبار مصرف

همان طور که در بخش مقدمه اشاره کردیم، در تراکنش‌‌ها هیچ فیلدی با عنوان «از طرف … » وجود ندارد. به جای آن از محاسبه باecrecover  استفاده می‌‌شود. در اینجا این پرسش ایجاد می‌‌شود که «اگر در بخش امضای تراکنش هرچه دلمان خواست بگذاریم چه می‌‌شود؟». گویا در زمینه‌‌ی بازپس دادن کلید عمومی (و البته آدرس همراه آن) به وسیله‌‌ی ecrecover تنها نیمی از امضاها معتبر هستند. از آنجایی که ما هیچ کنترلی روی اینکه آدرس چه باشد نداریم، کار ما در حقیقت ساختن تراکنشی است که می‌‌توان به وسیله‌‌ی آن از یک آدرس به ظاهر رندوم وجوهی را پرداخت کرد.

اگر ما چنین تراکنشی ایجاد کنیم و سپس در آدرس به وجود آمده مقداری اتر بگذاریم، امکان انجام یک تراکنش به صورت عادی فراهم می‌‌گردد. در این صورت ما یک «آدرس تک کاره» ایجاد کرده‌‌ایم که از آن می‌‌توانیم مبالغ را تنها با یک تراکنش خرج کنیم. اگر تراکنشی ارسال کنیم و برای فیلد امضاء مقادیری را برگزینیم آنگاه می‌‌توانیم به هرکسی ثابت کنیم که مبالغ ارسال شده به آن آدرس تنها به وسیله‌‌ی آن تراکنش قابل استفاده خواهند بود و نه هیچ چیز دیگر.

نحوه ارسال تراکنش‌‌ها در اتریوم

در تصویر بالا هدف این است که تراکنش‌‌ها به 11,140 مقصد فرستاده شوند. در این تصویر یک سری تراکنش ایجاد شده‌‌اند که اتر را به چندین آدرس می‌‌فرستند (هر تراکنش به 110 آدرس) و با فرآیندی که در بالا شرح داده شد، برای اترهای فرستاده شده آدرس‌‌هایی ایجاد می‌‌کنند. ما فیلدهای امضاء را با 0xDA0DA0DA0… پر می‌‌کنیم که یک میزان قابل پیش‌‌بینی است. به این ترتیب می‌‌توانیم مطمئن شویم هیچ کس برای آدرس‌‌های ساخته شده کلید خصوصی در اختیار ندارد.

به این ترتیب یک سری تراکنش با «آدرس‌‌های یکبار مصرف» به وجود می‌‌آید که می‌‌توان برای ارسال پول از آن‌‌ها استفاده کرد. 104 تراکنش با اینکه کم است ولی برای اینکه به دست یک متولی امضاء گردد زیاد است. به همین خاطر ما این فرآیند را یک بار دیگر تکرار می‌‌کنیم و با ایجاد یک الگوی آبشاری (cascade)، تراکنش دیگری می‌‌سازیم که اترها را به 104 تراکنش ساخته شده در گام نخست می‌‌فرستد. به این ترتیب یک تراکنش یگانه با آدرس منحصر به فرد ایجاد می‌‌شود. پس از تایید این امر که کد نوشته شده آن گونه که باید کار می‌‌کند، هرکسی می‌‌تواند با دادن تراکنش به شبکه فرآیندی را آغاز کند که حاصل آن فرستادن اتر به همه‌‌ی افراد موجود در لیست است و برای همه‌‌ی این‌‌ها تنها یک تراکنش نیاز است.

منبع

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

ارسال پاسخ

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