کینتسوگی (Kintsugi) شبکه آزمایشی که برای تست ادغام اتریوم ۲.۰ راه‌اندازی شده بود با اولین فورک خود مواجه شد و این موضوع باعث شد که این بلاکچین گواه اثبات سهام به صورت چندین نسخه موازی اجرا شود. این اولین حادثه از ابتدای آغاز به کار کینتسوگی در ماه دسامبر تاکنون است.
به گزارش میهن بلاکچین و به نقل از کریپتو اسلیت، رویداد ادغام در شبکه اتریوم، انتقال از مدل کنونی گواه اثبات کار به مدل اجماع گواه اثبات سهام است. این ادغام بدان معنا است که سیستم شبکه اصلی اتریوم و بیکن چین جدید که به آن اتریوم ۲.۰ گفته می‌شود، به صورت یک بلاکچین واحد ادغام خواهند شد.
به منظور تست این ادغام، شبکه آزمایشی کینتسوگی در ماه دسامبر شروع به کار کرد. هدف این شبکه آزمایشی، اجرای شرایط و مشکلات پیچیده و شدید و مشاهده نحوه رفتار سیستم است. یکی از توسعه‌دهندگان حاضر در اجرای تست‌های کینتسوگی، ماریوس ون در ویدن (Marius van der Wijden) است که از توسعه‌دهندگان اصلی اتریوم بوده و با تیم کلاینت گث (Geth) نیز همکاری می‌کند.
ماریوس ون در ویدن در این خصوص گفته است:
این شبکه آزمایشی به مدت چند هفته بدون مشکل اجرا شد و کار می‌کرد. هفته گذشته، فازری (fuzzer یا روش آزمایش خودکار نرم‌افزار) ایجاد کردم که بلاک‌های نامعتبر را ارسال می‌کرد. یک بلاک شامل اطلاعات بسیار زیادی نظیر تراکنش‌ها، هش بلاک قبلی، سقف گس و سایر موارد است.
بعضی از راهکارها اجرا نشدند و بلاک را تایید کردند
فازر، نوع رایجی از ابزار آزمایشی است که در بین توسعه‌دهندگان استفاده می‌شود تا ورودی‌های تصادفی یا کدهای دیگر ایجاد شود. سپس فازر در صدد شکستن این ورودی یا کدها برمی‌آید. هدف فازر، تولید ورودی‌های ناقص و غیرمنتظره و مشاهده اتفاقاتی است که برای سیستم رخ می‌دهد.
فازر ایجادشده توسط ون در ویدن یک بلاک معتبر تولید کرده و یکی از المان‌های آن را تغییر می‌دهد تا بلاک مذکور نامعتبر شود. یکی از روش‌هایی که این فازر استفاده می‌کند، تغییر یک المان به المان دیگر است. در این مورد، این فازر هش بلاک را به هش مادر (هش اصلی) تغییر داده است.
ون در ویدن در این خصوص گفت:
نودها باید چنین بلاک تغییریافته‌ای را نپذیرند. هرچند، از آنجایی که هش مادر خود را به سمت بلاک معتبر برده بود، بعضی از تست‌ها اجرا نشدند و بلاک را بررسی نکردند، اما در عوض در یک کَش (cache) به دنبال هش مادر بودند. از آنجایی که بلاک قبلی معتبر و داخل کش بود، نودها فرض می‌کردند که بلاک جدید نیز معتبر است.
فورک شدن ۲ بار اتفاق افتاد
نتیجه کار این بود که نیمی از شبکه یعنی کلاینت‌های گث این بلاک را نپذیرفتند، در حالی که نیمی دیگر از شبکه یعنی کلاینت‌های ندرمایند (Nethermind) و بسو (Besu) این بلاک را پذیرفتند. این موضوع باعث شد که زنجیره تفکیک شود زیرا اکنون دو نسخه متفاوت از وضعیتی صحیح داشتیم. ماجرا هنگامی بدتر می‌شود که مشکل دیگری به وجود آمد.
طبق گفته ون در ویدن، تفکیک دیگری بین نودهای زنجیره گث که شامل کلاینت‌های لایتهوس (Lighthouse)، پریزم (Prysm)، لودستار (Lodestar)، نیمبوس (Nimbus) و تکو (Teku) هستند به وجود آمد.
ون در ویدن در این خصوص گفت:
این تفکیک زنجیره هنوز در حال بازرسی است، اما به نظر می‌رسد کلاینت بسو دارای مکانیزم کشینگ (caching) بوده که با شکست مواجه شده است.
از آنجایی که در حال حاضر چندین فورک مختلف از شبکه آزمایشی کینتسوگی وجود دارد و هر نود فکر می‌کند که در فورک صحیح قرار دارد، شبکه دیگر عملیات‌ها را نهایی‌سازی و پردازش نمیکند.
ون در ویدن گفته است:
به شرایطی دست یافته‌ایم تا شبکه را به وضعیت مناسب برگردانیم. هم‌اکنون کلاینت ندرمایند را به‌روزرسانی کرده‌ایم و نودهای آن اکنون در زنجیره صحیح قرار دارند. هم‌چنان باید کلاینت تکو را اصلاح کنیم زیرا بیش از ۳۳ درصد نودها در تکو قرار دارند. در غیر اینصورت زنجیره عملیات را نهایی‌سازی نمیکند.
نکات مثبت این آزمایش
طبق گفته ون در ویدن، این اتفاق مانع از آزمایش بیشتر ادغام اتریوم نمی‌شود یا آن را به تعویق نمی‌اندازد. در واقع، ون در ویدن گفته است این اتفاق به آزمایش شرایط پیچیده و حادی کمک می‌کند که در صورت اجرای صحیح شبکه، آزمایش آن دشوار بوده است.
دوره‌های بلند عدم نهایی‌سازی برای نودها چالش برانگیز است و واکنش و رفتار آنها به این شرایط نکته بسیار مهمی برای ما محسوب می‌شود. ما معتقدیم که شبکه آزمایشی کینتسوگی سرانجام به شرایط مناسب برمی‌گردد، اما به نظرم به اصلاح دستی آن نخواهیم پرداخت، زیرا این فرصت را به ما می‌دهد تا شرایط و مشکلات جالبی را آزمایش کنیم.
وی در ادامه توضیح داد این اتفاق، ادغام اتریوم را به تعویق نمی‌اندازد، زیرا هنوز زمانبندی مشخصی برای ادغام وجود ندارد. اما این موضوع اهمیت آزمایش را نشان می‌دهد. به نظرم فرایند ادغام واقعا به خوبی پیش می‌رود. ما به چند هفته دیگر نیاز داریم تا نرم‌افزار مذکور را در وضعیت قابل دسترس قرار دهیم و سپس به چند ماه برای آزمایش آن نیاز داریم.
اگر این اتفاق برای شبکه اصلی رخ دهد چه شرایط پیش می‌آید؟
سوال جالبی که مطرح می‌شود این است که اگر چنین باگی برای زنجیره اصلی رخ دهد چه اتفاقی می‌افتد.
ون در ویدن بیان کرده است:
ما آزمایش را بسیار زود شروع کردیم، بنابراین انتظار وجود چنین باگ‌هایی را داشتیم. هرچند چنین باگی در شبکه اصلی بسیار شرایط نامناسبی به وجود می‌آورد زیرا باید باگ مذکور را پیدا و اصلاح کنیم که در این زمینه بسیار ماهر هستیم. سپس کد مذکور را عرضه کنیم و تمام سهام‌گذاران این موضوع را متوجه شوند که باید نودهای خود را به‌روزرسانی کنند. به نظرم بخش آخر، قسمت سخت این موضوع است زیرا بعضی از کاربران، فرایند توسعه را به دقت دنبال نمی‌کنند.
