راهنمای DAG برای مبتدیان

گراف‌‌های جهت‌‌دار

برای فهم Tangle‌‌ باید موضوعی که متخصصین کامپیوتری آن را با عنوان گراف‌‌های مستقیم می‌‌شناسند، را یاد بگیریم. یک گراف مستقیم، مجموعه‌‌ای از رئوس (مربع‌‌ها) می‌‌باشد که توسط گوشه‌‌ها (فلش‌‌ها) به هم متصل می‌‌شوند. اینجا مثالی از یک گراف مستقیم را داریم:

Tangle‌‌ که ساختار داده‌‌ای پشت IOTA است، نوع خاصی از گراف مستقیم است که تراکنش‌‌ها را در اختیار دارد (ذخیره می‌‌کند). هر تراکنش به عنوان یک راس در گراف نشان داده می‌‌شود. وقتی که یک تراکنش جدید وارد Tangle‌‌ می‌‌شود، بین دو تراکنش قبلی به منظور تایید انتخاب صورت می‌‌دهد و دو گوشه جدید به گراف اضافه می‌‌کند. در مثال بالا، تراکنش شماره 5، تراکنش شماره 2 و 3 را تایید می‌‌کند.

تراکنش‌‌ها کم و بیش همان چیزی هستند که انتظار دارید و چنین اطلاعاتی دارند: فرد الف به فرد ب، 10 IOTA می‌‌دهد. در این سطح خیلی نگران مفهوم تایید تراکنش نیستیم، زیرا که بعدا به این موضوع خواهیم پرداخت.

ما به تراکنش‌‌های تایید نشده، فراز (tip) می‌‌گوییم. در این مثال، تراکنش شماره 6 یک فراز است، زیرا هیچکس آن را تا به حال تایید نکرده است. هر تراکنش ورودی نیازمند انتخاب دو فراز برای تایید است (همیشه حداقل یک گزینه موجود است!). روش و استراتژی انتخاب کدام 2 فراز برای تایید، بسیار مهم است و کلید فناوری منحصر به فرد IOTA محسوب می‌‌شود. هرچند برای ساده‌‌تر کردن زندگی‌‌هایمان، ما با ساده‌‌ترین استراتژی آغاز خواهیم کرد: انتخاب تصادفی بین تمام فرازهای موجود. هر تراکنش ورودی به تمام تراکنش‌‌های تاییدنشده موجود نگاه می‌‌کند و به سادگی 2 گزینه را به صورت تصادفی انتخاب می‌‌کند.

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

نرخ‌‌های تراکنش و نهفتگی شبکه

در شبیه‌‌سازی قبلی، شاید توجه کرده‌‌ باشید که تراکنش‌‌ها به صورت مساوی در گذر زمان پخش نشده‌‌اند، اما برخی دوره‌‌ها نسبت به دیگر دوره‌‌ها مشغول‌‌تر هستند. این تصادفی بودن که باعث واقعی‌‌تر شدن مدل می‌‌شود، با استفاده از فرایند نقطه‌‌ای پواسون به دست می‌‌آید تا بتواند نحوه انجام تراکنش‌‌ها را بیان کند. این مدل برای تحلیل این که مشتریان متعدد در یک بازه مشخص به یک فروشگاه می‌‌روند یا چه تعداد تماس تلفنی برای ارتباط با یک مرکز تلفنی برقرار می‌‌شود، بسیار معمول است. می‌‌توانیم این رفتار را در مثال Tangle زیر مشاهده کنیم. تراکنش‌‌های 4 ،5 و 6 تقریبا به صورت همزمان رسیده‌‌اند و بعد از تراکنش 6، یک مکث بسیار طولانی وجود داشته است.

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

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

تعداد λ بسیار کوچک، یک زنجیره را تولید می‌‌کند (ساختار شبیه به بلاک‌‌چین)

λ بسیار کوچک: فقط پیدایش قابل مشاهده است.

حالا منظور ما از عدم مشاهده تراکنش قبلی چیست؟ در مدل، ما هر تراکنش را برای مدت مشخصی بعد از رسیدن آن، نامرئی می‌‌کنیم. ما این دوره تاخیر را با حرف h مشخص می‌‌کنیم. این تاخیر بیانگر زمان مورد نیاز تراکنش برای آماده‌‌سازی و گسترش در شبکه است. در شبیه‌‌سازی، ما همیشه h=1 در نظر می‌‌گیریم. این به آن معنا است که می‌‌توانیم فقط تراکنش‌‌هایی را تایید کنیم که حداقل در گذشته یک واحد زمانی بوده‌‌اند. این تاخیر فقط یک ویژگی جزیی دربه منظور واقعی‌‌کردن بیش از حد نبود، بلکه ویژگی اساسی Tangle محسوب می‌‌شد که بدون آن ما همیشه یک زنجیره بسیار خسته‌‌کننده خواهیم داشت. این ویژگی همچنین باعث نزدیک‌‌تر شدن کلاف به دنیای واقعی می‌‌شود و کمی زمان می‌‌برد تا مردم به یکدیگر درباره تراکنش‌‌های جدید اطلاع دهند.

گام تصادفی

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

می‌‌توانید مسیر گام‌‌زن را با علامت قرمز مشاهده کنید و مسیرهای ممکن در تقاطع‌‌های دیگر هم با رنگ آبی مشخص شده‌‌اند. تازه‌‌ترین تراکنش‌‌ها که نسبت به گام تصادفی فعلی نامرئی هستند هم به صورت شفاف نشان داده شده‌‌اند.

گام تصادفی وزن‌‌شده و وزن تجمعی

بگذارید برای آموزش آن، با چند محرک شروع کنیم. یکی از مسائلی که می‌‌خواهیم الگوریتم انتخاب فراز ما از آن دوری کند، فرازهای کند (lazy tips) است. فراز کند فرازی است که تراکنش‌‌های قدیمی را در عوض تراکنش‌‌های جدید تایید کند. این فراز به آن خاطر کند است که با جدیدترین وضعیت Tangle همراه نشده و فقط تراکنش‌‌های خود را بر اساس داده‌‌های قدیمی‌‌اش منتشر می‌‌کند. این مسئله به شبکه کمک نمی‌‌کند زیرا که هیچ تراکنش جدیدی تایید نمی‌‌شود.

در مثال بالا تراکنش 14 یک فراز کند است که برخی از تراکنش‌‌های بسیار قدیمی را تایید می‌‌کند. اگر ما از الگوریتم گزینش یکپارچه و تصادفی فراز استفاده کنیم، تراکنش 14 به اندازه باقی تراکنش‌‌ها شانس تایید دارد، پس اصلا شامل جریمه‌‌ای نخواهد شد. با استفاده از گام وزن‌‌شده، این رفتار بد، حداقل در این شبیه‌‌سازی ما حتی تشویق هم می‌‌شود.

حالا ما چگونه با چنین مشکلی دست و پنجه نرم می‌‌کنیم؟ یکی از چیزهایی که نمی‌‌توانیم انجام دهیم، فشار به شرکت‌‌کنندگان برای تایید تراکنش‌‌های تازه است، زیرا چنین موضوعی می‌‌تواند کل ایده و فلسفه تمرکز زدایی را به خطر بیاندازد. تراکنش‌‌ها می‌‌توانند هر کسی را که بخواهند تایید کنند. همچنین ما یک روش مطمئن برای مشخص کردن زمان دقیق تراکنش‌‌ها نداریم پس نمی‌‌توانیم چنین قانونی را با فشار وضع کنیم. راه‌‌حل ما‌‌، ساخت سیستم اختصاصی همراه با انگیزه‌‌های درونی در مقابل چنین رفتاری است تا فرازهای کند نتوانند توسط هیچ کسی تایید شوند. استراتژی ما حمایت از گام تصادفی‌‌مان خواهد بود تا فرازهای کند را کمتر انتخاب کنیم. ما از وزن تجمعی استفاده خواهیم کرد تا اهمیت تراکنش را مشخص کنیم. احتمالا به سمت تراکنش‌‌های سنگین‌‌تر حرکت خواهیم کرد. معنی وزن تجمعی بسیار ساده است: ما روی میزان تاییدکنندگان تراکنش تمرکز و یک مورد را اضافه می‌‌کنیم. تاییدکنندگان مستقیم و غیرمستقیم را هم شمارش می‌‌کنیم. در مثال زیر، تراکنش 3، وزن تجمعی 5 دارد زیرا که 4 تراکنش تاییدی در اختیار دارد (5 به صورت مستقیم، 7، 8 و 10 غیرمستقیم).

چرا این مسئله جواب می‌‌دهد؟ بیایید بار دیگر به شرایط فراز کند نگاهی بیاندازیم. در مثال زیر تراکنش 16 یک فراز کند است. به منظور تایید تراکنش 16، گام‌‌زن تصادفی باید به تراکنش 7 برسد و سپس تراکنش 16 را به جای تراکنش 9 انتخاب کند. اما رخداد چنین اتفاقی بعید است، زیرا که تراکنش شماره 16 وزن تجمعی 1 و تراکنش 9 وزن تجمعی 7 دارد! این یک روش موثر برای نکوهش رفتار کند است.

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

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

ما به روشی برای تعریف احتمال حرکت به سمت تایید کننده مشخص در هر تقاطع نیاز داریم. تا زمانی که از تراکنش‌‌‌‌های سنگین‌‌تر حمایت کنیم، فرمول دقیقی که انتخاب می‌‌کنیم مهم نیست و پارامتری برای کنترل میزان قدرت این حمایت داریم. این مسئله از پارامتر جدید ما، α رونمایی می‌‌کند و این پارامتر میزان اهمیت وزن تجمعی تراکنش را مشخص می‌‌کند. تعریف دقیق آن را می‌‌توان در وایت پیپر IOTA مشاهده کرد.

گام تصادفی وزن‌‌شده: هر تراکنش آبی بیانگر وزن تجمعی آن و احتمال انتخاب به عنوان قدم بعدی در گام می‌‌باشد.

اگر ما α را روی صفر تنظیم کنیم، بار دیگر به گام وزن‌‌نشده بازمی‌‌گردیم. اگر ما α را خیلی بالا در نظر بگیریم، گام شدیدا وزن‌‌شده خواهیم داشت. در این میان، می‌‌توانیم تعادل خوبی بین مجازات رفتار کند و جا نگذاشتن بسیاری از فرازها پیدا کنیم. تعیین میزان ایده‌‌آل α یک موضوع مهم در تحقیق IOTA محسوب می‌‌شود.

این روش تنظیم قانون برای تعیین احتمال هر مرحله در گام تصادفی با عنوان تکنیک زنجیره مارکوف مونت‌‌کارلو (Markov Chain Monte Carlo) یا MCMC شناخته می‌‌شود. در زنجیره مارکوف هر قدم به قدم قبلی بستگی ندارد، اما از قانونی تبعیت می‌‌کند که از پیش تعیین شده‌‌ است.

مثل همیشه ما یک شبیه‌‌سازی برای نشان دادن این ایده‌‌های جدید داریم. توصیه می‌‌کنم با مقادیر α و λ کار کنید و ببینید چه کلاف‌‌های جذابی را به دست می‌‌آورید.

تاییدکنندگان، تعادل‌‌ها (ترازها) و خرج‌‌های دوباره

تا به حال درباره DAGها، گام‌‌های تصادفی و مکانیسم‌‌های گزینش مختلف فراز صحبت کرده‌‌ایم: اکنون می‌‌خواهیم درباره پول صحبت کنیم. می‌‌خواهیم توضیح دهیم که منظورمان از تراکنش الف تراکنش ب را تایید می‌‌کند، چیست.

همانطور که بالاتر توضیح دادیم، هر تراکنش حاوی اطلاعاتی در قالب “آلیس به باب 10 IOTA داد” می‌‌باشد. وظیفه تاییدکننده است که مطمئن شود آیا آلیس 10 IOTA را در اختیار دارد یا نه.

شاید اینجا تعجب کنید: این IOTA از کجا آمده‌‌اند؟ پاسخ این است که آن‌‌ها از همان اولین تراکنش درون Tangle با عنوان “تراکنش پیدایش” ایجاد شده بودند. هیچ IOTA اضافی هرگز ساخته نخواهد شد. از پیدایش، IOTAها به نسبت میزان سرمایه‌‌گذاران در پروژه به حساب‌‌های آن‌‌ها منتقل شده‌‌است. سپس آن‌‌ها برخی از IOTA خود را به دیگران فروختند و به تدریج یک شبکه خرید و فروش ایجاد شده ‌‌است.

با نگاه به مثال ساده آلیس و باب، بیایید برخی مسائل را بررسی کنیم. کادر زیر بیانگر یک تراکنش است. برای آسودگی بیشتر ما پیش از انجام تراکنش، ترازهای حساب‌‌های آلیس و باب را هم می‌‌نویسیم. مشاهده می‌‌کنیم که در ابتدا، آلیس 10i داشته که آن را به باب داده و سپس باب 10i دارد و آلیس هیچ چیزی برای خود نمی‌‌بیند.

سرانجام یک نفر، فرض کنیم چارلی، می‌‌خواهد پرداخت خود را انجام دهد. او به الگوریتم گزینش فراز می‌‌رود و متوجه می‌‌شود باید تراکنش آلیس را تایید کند. برای انجام چنین کاری او باید تایید کند که آلیس 10i را در اختیار داشته‌‌است. چارلی بهتر است این مسئله را جدی بگیرد: اگر او یک تراکنش بد را تایید کند، تراکنش او هرگز تایید نخواهد شد!

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

پیدایش با 15i ایجاد می‌‌شود

1. پیدایش به باب 2i می‌‌دهد.
2. پیدایش به آلیس 8i می‌‌دهد.
3. پیدایش به چارلی 5i می‌‌دهد.
4. چارلی به دانا 3i می‌‌دهد.
5. باب به آلیس 2i می‌‌دهد.

البته این فقط یکی از گزینه‌‌ها است: تمام فهرست‌‌هایی که 10i برای آلیس و 0 برای باب به همراه داشته باشد، قابل قبول است. همچنین چارلی باید حساب تمام دیگر حساب‌‌های سیستم را هم داشته باشد تا مطمئن شود هیچکدام به زیر صفر نمی‌‌روند: اگر هر کدام از ترازها قبل یا بعد از بخش‌‌ها منفی شوند، تراکنش او نامعتبر خواهد بود.

بیایید نگاهی به موردی بیاندازیم که آلیس می‌‌خواهد IOTA بیشتر از دارایی خود منتقل کند:

آلیس با اینکه فقط 10i دارد، به باب 100i می‌‌دهد. تراکنش آلیس و تمام تراکنش‌‌های بعدی که آن را تایید کنند توسط شبکه به صورت نامعتبر در نظر گرفته می‌‌شوند. ترازهای منفی هم مجاز نیستند.

این شرایط هنگامی که ما به جای یک تراکنش، دو تراکنش را تایید می‌‌کنیم، جذاب‌‌تر هم می‌‌شود:

باب در تایید تراکنش‌‌های آلیس به درستی عمل کرد، زیرا آلیس در حساب خود پول کافی برای پرداخت و منفی نشدن داشت.

حالا اگر مبلغ کلی از دارایی او بیشتر باشد چه اتفاقی می‌‌افتد؟ این مسئله در کادرهای زیر آمده ‌‌است. در این مورد، باب نمی‌‌تواند هیچ‌‌کدام از دو تراکنش آلیس را تایید کند، زیرا سبب ایجاد تراز منفی برای آلیس می‌‌شوند. اگر باب این کار را انجام دهد، او قوانین پروتکل IOTA را زیر پا گذاشته و هیچکس تراکنش جدید او را تایید نخواهد کرد.

این وضعیت آخر با عنوان خرج دوباره (double spending) شناخته می‌‌شود، زیرا آلیس پول خود را دو بار خرج کرده ‌‌است. توجه کنید که او پروتکلی را زیر پا نگذاشته، زیرا پول کافی برای هر کدام از تراکنش‌‌ها را در اختیار داشته ‌‌است. شاید او حتی قصد خرج دوباره را هم نداشته و تراکنش‌‌ها را به اشتباه دو بار ارسال کرده است. در هر حال دو شاخه در Tangle ایجاد کرده و نمی‌‌توان آن‌‌ها را تطبیق داد. این کار باعث ایجاد مشکل برای کاربران صادق IOTA می‌‌شود: آن‌‌ها باید کدام شاخه را تایید کنند؟

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

توافق، اطمینان تایید و هماهنگ‌‌کننده

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

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

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

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

فرض کنید باب و چارلی فروشندگان دایناسور (dinosaur dealers) هستند و آلیس یک حیوان خانگی (اسباب‌‌بازی) تی‌‌رکس از هر کدام از آن‌‌ها خریده است. اگر هر دوی آن‌‌ها بلافاصله پس از مشاهده تراکنش در Tangle، برای آلیس تی‌‌رکس ارسال کنند، در نهایت یکی از آن‌‌ها متوجه خواهد شد که پولی دریافت نکرده است. آن‌‌ها از کجا بفهمند که ارسال این دایناسور برای آن‌‌ها خطری در بر ندارد؟

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

1- الگوریتم گزینش فراز را 100 بار اجرا کنید.

2- بشمارید که چند فراز از این 100 فراز، تراکنش ما را تایید می‌‌کنند و آن را A بنامید.

3- اطمینان تایید تراکنش ما، A درصد خواهد بود.

به بیان دیگر، اطمینان تایید یک تراکنش، درصدی از فرازهایی است که آن را تایید می‌‌کنند. تمامی فرازها به صورت مساوی در نظر گرفته نمی‌‌شوند؛ فرازهای محتمل‌‌تر، اهمیت بیشتری هم دارند. برای بیان چنین نکته‌‌ای، بیایید اطمینان تایید را به شبیه‌‌سازی اضافه کنیم. تراکنش‌‌های همراه با اطمینان بالای 95 درصد با حاشیه پر رنگ (ضخیم) مشخص شده‌‌اند.

در Tangle بالا، تراکنش شماره 9، توسط دو فراز از 4 فراز تایید شده ‌‌است. اگر ما از گزینش فراز تصادفی یکپارچه استفاده می‌‌کردیم، اطمینان دقیقا 50 درصد می‌‌شد. هرچند فرازهایی که آن را تایید می‌‌کنند، احتمالا بیشتر از فرازهایی باشند که تاییدی انجام نمی‌‌دهند و این مسئله، اطمینان را کمی بالا می‌‌برد.

حالا مشخص شد که باب و چارلی چه زمانی می‌‌توانند بفهمند که آیا ارسال تی‌‌رکس به آلیس، مطمئن هست یا خیر. وقتی که تراکنش آلیس به آستانه اطمینان بسیار بالایی رسید، فرض کنیم اطمینان 95 درصد، خروج او از توافق بسیار بعید خواهد بود. باید مراقب باشیم و بگوییم “بسیار بعید” و از عبارت غیرممکن استفاده نکنیم؛ اگر آلیس بخواهد تقلبی صورت دهد و نیروی رایانشی کافی داشته باشد، می‌‌تواند خرج دوباره انجام دهد.

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

این حمله در Tangle زیر نشان داده شده است و زمان به سمت عقب رفته:

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

از آنجایی که IOTA برای مقیاس‌‌گذاری ساخته شده، به دلایل امنیتی ما از یک مکانیسم توافقی موقتی و داوطلبانه دیگر استفاده می‌‌کنیم: هماهنگ‌‌کننده. هر دو دقیقه، یک تراکنش برجسته (milestone) از سوی موسسه IOTA توزیع می‌‌شود و تمام تراکنش‌‌های تاییدشده توسط آن، فورا با اطمینان تایید 100 درصدی توزیع (ارسال) می‌‌شوند. با استفاده از هماهنگ‌‌کننده، تراکنش دوم آلیس هرگز از همان ابتدا تایید نمی‌‌شد. این مسئله به عنوان یک مکانیسم حمایتی عمل می‌‌کند، در حالیکه شبکه IOTA به سمت فعالیت ضروری از پذیرش مورد نیاز برای حفظ ایمنی شبکه در یک حالت 100 درصد نامتمرکز، رشد می‌‌کند و اینجا است که الگوریتم توافقی توزیع‌‌شده کامل، وارد می‌‌شود. در این نقطه، موسسه IOTA، هماهنگ‌‌کننده را لغو خواهد کرد و به Tangle اجازه می‌‌دهد تا کاملا روی پای خودش بایستد و پیشرفت کند. این مسئله در فازهای مکرر رخ خواهد داد. وقتی که شبکه به اندازه کافی بالغ شد و توانست از شر هماهنگ‌‌کننده خلاص شود، شبکه هم فورا به طور موثرتری عمل خواهد کرد.

این موضوع چه تفاوتی با بلاک‌‌چین‌‌ها دارد؟

تفاوت DAGها با بلاک‌‌چین‌‌ها این است که DAG ساختار اصلی ذخیره تراکنش‌‌های ما را تغییر می‌‌دهد. این تغییر هرچند هم کوچک به نظر برسد، نحوه نگاه ما به وقوع مسائل شبکه را تغییر می‌‌دهد. این تغییر باعث قدرتمندتر شدن سیستم به نسبت بلاک‌‌چین می‌‌شود. اما همیشه مشکلاتی هم وجود دارد. این افزایش در مقیاس پذیری باعث کاهش امنیت، احتمال بیشتر متمرکزسازی و عدم کفایت پشتیبانی مناسب از قراردادهای هوشمند می‌‌شود.