پادکست هجیو 🎧

در ادامه‌ی این پست، حتماً کنجکاو خواهید شد اگر بدونید که بنیاد تتر تا امروز ۱۲۵۳ بار آدرس‌هایی از شبکه‌های اتریوم و ترون که شاید به اشتباه وارد بلک‌لیست خودش شده بودند رو از این لیست خارج کرده. این آدرس‌ها و تراکنش‌های مربوط به Remove رو در این لینک می‌تونید ببیند (برگرفته از این دیتاست): https://gist.github.com/eferbarn/a7e0de96bcf83ec61dafa123ba40be7e البته برای دیدن تراکنش‌های مربوطه باید بدونید که چون مالتی‌سیگ (اونر) کانترکت تتر تراکنش‌ها رو ارسال می‌کنه (این آدرس دارای ۶ ساینر هست که از این‌جا می‌تونید اون‌ها رو ببینید) و بعد از شرایط خاصی تراکنش کانفرم میشه، باید ابتدا از دیتای تراکنش آی‌دی تراکنش اصلی رو پیدا کنید و بعد از طریق این متد (transactions) کال‌دیتای تراکنش Remove رو استخراج کنید. برای راحتی کار اطلاعات کافی در لینک gist قرار داده شده تا شما درگیر این مراحل نشید. 💚 Website | @hedgio_fa

در ادامه‌ی این پست، حتماً کنجکاو خواهید شد اگر بدونید که بنیاد تتر تا امروز ۱۲۵۳ بار آدرس‌هایی از شبکه‌های اتریوم و ترون که شاید به اشتباه وارد بلک‌لیست خودش شده بودند رو از این لیست خارج کرده. این آدرس‌ها و تراکنش‌های مربوط به Remove رو در این لینک می‌تونید ببیند (برگرفته از این دیتاست): https://gist.github.com/eferbarn/a7e0de96bcf83ec61dafa123ba40be7e البته برای دیدن تراکنش‌های مربوطه باید بدونید که چون مالتی‌سیگ (اونر) کانترکت تتر تراکنش‌ها رو ارسال می‌کنه (این آدرس دارای ۶ ساینر هست که از این‌جا می‌تونید اون‌ها رو ببینید) و بعد از شرایط خاصی تراکنش کانفرم میشه، باید ابتدا از دیتای تراکنش آی‌دی تراکنش اصلی رو پیدا کنید و بعد از طریق این متد (transactions) کال‌دیتای تراکنش Remove رو استخراج کنید. برای راحتی کار اطلاعات کافی در لینک gist قرار داده شده تا شما درگیر این مراحل نشید. 💚 Website | @hedgio_fa

در ادامه‌ی این پست، حتماً کنجکاو خواهید شد اگر بدونید که بنیاد تتر تا امروز ۱۲۵۳ بار آدرس‌هایی که شاید به اشتباه وارد بلک‌لیست خودش شده بودند رو از این لیست خارج کرده. لیست این آدرس‌ها و تراکنش‌ها رو در این لینک می‌تونید ببیند:

آیا در این لحظه باید نگران کامپیوترها و پردازش کوانتومی باشیم؟ (این صرفاً یک اظهار نظر بسیار عامیانه از بنده است در باب این پست از کانال دیفای اونیو) واقعیت اینه که خروجی ناگوار این قضایای به‌ظاهر طبقه بندی‌شده، قبل از این‌که اثرش رو روی کریپتو (به‌عنوان یکی از کوچک‌ترین اعضای دنیای تکنولوژی) بذاره، ضربه‌ی بسیار بزرگی به Institutionalها خواهد زد. دنیایی رو تصور کنید که هیچ‌گونه حریم خصوصی‌ای در اون مفهومی نداره. فرض کنید داریم درمورد شکسته‌شدن پسوردهای تمام افراد کوچک و بزرگ در دنیا حرف می‌زنیم. اینه که اگر قرار باشه این مفاهیم از مراحل فعلیش بگذره، افراد و نهادهای بسیار بزرگ‌تری از ما و کل کریپتو با اون مقابله خواهند کرد. پی‌نوشت: خیلی اتفاقی یاد سری تلویزیونی Prime Target افتادم. نام این اثر اشاره‌ی واضحی به معادل انگلیسی «اعداد اول» داره. احتمالاً می‌دونید که شالوده و اساس بسیاری از سیستم‌های رمزنگاری امروزی نبود الگو در اعداد اول و غیرقابل‌پیش‌بینی بودن توزیع اون‌هاست. فکر می‌کنم از دیدن این سری خوشتون خواهد اومد. پی‌نوشت دوم: حدس اینه که این توازن همیشگی (بین پیشرفت در پردازش و سیستم‌های رمزنگاری) به‌هم نخواهد خورد و ما به‌سمت روش‌های Quantum-Resistant پیش خواهیم رفت. 💚 Website | @hedgio_fa

این روزها که موضوع فریز شدن آدرس‌ها و رگیولیشن‌های سخت‌گیرانه بحث داغ محافل کریپتویی ماست، پیدا کردن یک ابزار مرتبط ولی ساده می‌تونه خیلی ارزشمند باشه،‌ پس با در نظر گرفتن یک‌سری از مهم‌ترین اوراکل‌ها یا کانترکت‌ها ابزاری ساختیم که بتونید با اون‌ها آدرس‌ها 0x خودتون یا بقیه رو چک کنید و قبل تعامل باهاشون از فلگ‌بودن اون‌ها مطلع بشید. https://0x.eferbarn.com درسته تا دلتون بخواد مرجع مثل TRM Labs یا Elliptic وجود داره، اما عموماً این‌ها پاسخ‌ها رو به شکل آف‌چین و دارای APIهای دارای محدودیت بالا هستن و در حال حاضر هم خیلی استفاده‌ی گسترده ندارن، پس فعلاً از قانون KISS تبعیت کردیم و به آدرس‌های 0x و اوراکل‌ها و کانترکت‌های مهم (تا این‌جای ماجرا احتمالاً این منابع کافی باشن) بسنده کردیم تا در آینده مراجع بیشتری رو بهش اضافه کنیم. این ابزار روی مرورگر شما اجرا میشه و فقط یک‌سری RPC Call می‌فرسته تا نتایج رو برگردونه. توییت مربوطه 💚 Website | @hedgio_fa

یکی از دوستان درمورد استفاده از نرم‌افزارهای مدیریت پسورد مردد بودن. خیلی اجمالی اگر بخوایم جواب بدیم، خوبه، کار رو راه میندازن، اما حواستون باشه خودشون می‌تونن عامل دردسر بشن. کما این‌که شواهدی وجود داره که درین شدن والت‌های اتریومی باسابقه که سال‌ها ایمن مونده بودن، مربوط به یک بریچ از نرم‌افزار مدیریت پسورد LastPass هست و نگهداری فریزها توی این نرم‌افزارها باعث این دسترسی کامل به آدرس‌ها شده. LastPass Breach Fallout + Ethereum Wallets Suddenly Drained 💚 Website | @hedgio_fa

تیم Circle که صادرکننده‌ی استیبل‌کوین USDC محسوب میشه و به تنبل‌بودنش در فریز کردن وجوه مشکوک در مقایسه با بنیاد تتر معروف بود، در یک اقدام عجیب کانترکت cUSDC از پروژه‌ی Zama (زاما یک پروژه در سکتور پرایوسی روی اتریوم محسوب میشه) رو فریز کرد که در اون حدود 12.6 میلیون دلار USDC وجود داشت. Circle blacklisted the Zama cUSDC contract طبق اعلام و بررسی ZachXBT، این اقدام به دلیل گزارش کاربران درمورد یک راگ‌پول از طرف تیم Overnight Finance و واریز وجوه مربوط به این اتفاق از طرف یکی از آدرس‌ها وابسته به همین ماجرا به پروژه‌ی زاما هست. چیزی که این‌جا مورد بحث هست اینه که چرا کانترکتی که می‌تونه آمیخته با وجوه کاربران عادی Zama بشه بلک‌لیست و فریز شده؟ مورد مهم‌تر برای ما اینه که به‌نظر می‌رسه مجموعه‌ی سرکل بعد از این می‌تونه رویکرد بنیاد تتر رو در پیش بگیره و این موضوع هر دو دارایی $USDT و $USDC رو به کلاس دارایی‌های پریسک منتقل کنه. 💚 Website | @hedgio_fa

برای ایردراپ شبکه‌ی بیس دوستان میگن که خیلی از شبیه‌سازهای ایردراپ، کانترکت‌های دپلوی شده توسط جاهایی مثل owlto رو حساب نمی‌کنن و اون‌ها رو نادیده می‌گیرن. اگرچه راه برای پیدا کردن کانترکت‌های کوچک و سمپل زیاده اما اگر خواستین می‌تونید از این ریپازیتوری قدیمی استفاده کنید: https://github.com/eferbarn/Simple-Solidity-Contracts برای ساده‌ترین روش دپلوی کردن هم می‌تونید سراغ Remix برید. کافیه والت‌تون رو وصل کنید و چین آی‌دی رو هم روی 8453 یا همون chainID مین‌نت بیس تنظیم کنید و بعد مراحل رو پیگیری کنید. (راهنما) 💚 Website | @hedgio_fa

تو این اپیزود مدیر اجرایی ایمیونفای داره با احسان صحبت می‌کنه و چه مسیر عجیبی رو طی کرده احسان. داستانش می‌تونه الهام‌بخش زندگی خیلی از ماها باشه. https://www.youtube.com/watch?v=BPkLUdMcPLY 💚 Website | @hedgio_fa

جلسه بحث آزاد ❗️ ⬅️ موضوع گفتگو : - قراره درمورد Polymarket و ریسک هاش حرف بزنیم. - قراره درمورد خطرات احتمالی سروها یا Vpn هایی که برای وصل شدن استفاده میکنیم حرف بزنیم. - مثل همیشه بحث آزاد هم هست شما میتونید بیاد درمورد هر موضوعی دوست داشتید باهم حرف بزنیم. ⬅️ با همکاری : مهدی کانال Hedgio محمد کانال CryptoCraze ⬅️زمان جلسه دوشنبه 4 خرداد ساعت 9 شب به تایم ایران ⬅️ مکان جلسه کانال تلگرام Defi Avenue 🎺 جلسه ضبط نمیشه ✉️ Telegram ❌ Twitter

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

chrome://certificate-manager

همچنین با جستجوری عبارت Certificate در تنظیمات کلی مرورگرتون هم به همین بخش خواهید رسید. به این ترتیب حتی اگر پراکسی ساخته‌شده توسط MitM رو روی کل سیستمتون هم اعمال کنید، باز فقط اینترنت (بدون اخطار) از طریق این پروفایل در دسترس هست و خودتون هم هر زمان بخواید می‌تونید حذف/تغییر مدنظر خودتون رو روی این پروفایل اعمال کنید. البته که برای این‌که پراکسی رو هم فقط روی همین مرورگر/پروفایل اعمال کنید راه‌های بسیار زیادی نظیر استفاده از اکستنشن FoxyProxy وجود داره که خب کنترل بیشتری رو به شما اعطا می‌کنه. این ترکیب در این شرایط می‌تونه معجزه کنه و جلوی خیلی از اشتباهات سهوی رو بگیره. برای دوستانتون بفرستید تا بتونیم باهم از این روزهای تاریک به سلامت گذر کنیم! 💚 Website | @hedgio_fa

در ادامه‌ی پست بالا باید دنبال راهکاری باشیم تا بتونیم خطرات بالقوه رو کاهش بدیم. پیش از ورود به بحث باید گفت که ما دست کسانی که به دسترسی افراد به اینترنت آزاد کمک می‌کنند رو می‌بوسیم و صدها لعنت می‌فرستیم به باعثان این شرایط. همون‌طور که می‌بینید وقتی Self-Hosted Authority ما یک سرتیفیکیت ایجاد کرده، سیستم‌عامل در تلاشه که اون رو در کل سیستم اعمال کنه و به‌عبارت دیگه اون رو به Trusted Root اضافه کنه. این باعث میشه که خطاهای انسانی یا دسترسی‌های ناخواسته وارد فرایند بشه. پس ما باید دنبال یک راهکار خوب برای استفاده‌ی مطمئن باشیم. مشکل از کجا ناشی میشه؟ 🟥 این فرایندها در ابتدا در کنترل شما هستند و خب تا این‌جا مشکلی نیست. اما پس از مدتی هیچ‌گونه الزامی وجود نداره که اپ‌ها یا جاسوس‌افزارهای دیگه اعم از اپلیکیشن‌ها یا چیزهایی که روی دسکتاپ یا موبایلتون دارید، دنبال فایل‌های مرتبط با رمزگشایی ترافیک شما نگردن. خصوصا در پلتفرم‌های همه‌گیری مثل اندروید و ویندوز خیلی از دسترسی‌ها به‌صورت ناخواسته از قبل داده شده و ممکنه در روزهای خاص از اون دسترسی‌ها استفاده بشه. 🟥 اگر روزی دسترسی آزاد واقعی به اینترنت برای شما فراهم بشه، احتمالا با فرایند ابطال اون سرتیفیکیت‌های قدیمی آشنایی ندارید یا حتی ممکنه یادتون بره که این سرتیفیکیت‌ها رو باطل کنید و از Trusted Root اون‌ها رو خارج کنید. بهترین راه اینه که بتونید یک Sandbox یا به‌عبارتی یک محیط قابل کنترل و امن ایجاد کنید تا هر لحظه روی اون و دیتایی که واردش می‌کنید اشراف کامل داشته باشید و در زمان نیاز هم حذفش کنید. در پست بعدی به بررسی یک راهکار ایمن در این زمینه می‌پردازیم. 💚 Website | @hedgio_fa

اگر ناچار به استفاده از این روش‌ها هستید، با جدیت بیشتری موضوع امنیت رو مدنظر داشته باشید. فایل‌های سرتیفیکیت رو به‌صورت دوره‌ای Rotate کنید و تا حد امکان امکان دستیابی هر فرد دیگری به این فایل‌ها رو ناممکن کنید. 💚 Website | @hedgio_fa

این روزها به‌طور فراگیر، روش‌هایی برای اتصال به اینترنت در حال گسترش هستن که در اون‌ها یک کلاینت (چه به‌صورت یک اسکریپت باشه و چه هر شکل دیگری) حکم MitM یا مرد میانی رو بازی می‌کنه. برای مثال تموم روش‌های منشعب شده از روش MHR از همین متد استفاده می‌کنن. در این روش‌ها با ایجاد شدن یک سرتیفیکیت Self-Hosted کلاینت می‌تونه ترافیکی عبوری از مرورگر (و سایر بخش‌های ماشین) شما که از این پراکسی گذر می‌کنه رو رمزگشایی کنه، و بعد دوباره اون‌ها رو با متد خودش ارسال و دریافت کنه. بگذریم که خود این کلاینت‌ها و امنیتشون یک نقطه‌ی شکست محسوب میشن، اما نکته‌ی اساسی، نگهداری فایل‌های سرتیفیکیت (یعنی cert و key) هست که اصلا به اون توجه نمیشه. خصوصاً جابه‌جایی اون‌ها بین دیوایس‌های مختلف و نگهداریشون به‌صورت خام داخل دایرکتوری‌ها، می‌تونه شما رو به‌طور بالقوه به یک طعمه تبدیل کنه. توجه داشته باشید که هر شخص ثالثی با داشتن این فایل‌ها، ترافیک شما رو رمزگشایی و شنود کنه. این شامل رمزها و کلیدهایی که تبادل می‌کنید هم هست. نباید کار به این نقطه می‌رسید که سراغ روش‌های با ریسک ساختاری بسیار بالا بریم، اما حالا که رسیدیم، چاره‌ای نیست که حواسمون خیلی جمع باشه. 💚 Website | @hedgio_fa

این روزها به‌طور فراگیر، روش‌هایی برای اتصال در حال گسترش هستن که در اون‌ها یک کلاینت حکم MitM یا مرد میانی رو بازی می‌کنه. برای مثال تموم روش‌های منشعب شده از روش MHR از همین متد استفاده می‌کنن. در این روش‌ها با ایجاد شدن یک سرتیفیکیت Local Hosted کلاینت می‌تونه ترافیکی که از مرورگر (و سایر بخش‌های ماشین) شما می‌ نباید کار به این نقطه می‌رسید که سراغ روش‌های با ریسک ساختاری بسیار بالا بریم، اما حالا که رسیدیم. چاره‌ای نیست که حواسمون خیلی جمع باشه.

بخش دو - پایانی

شما حالا باید این فایل‌ها رو از سرور یا لوکال خودتون به سرور مقصد منتقل کند (یا اگر فایل‌ها روی سرور مقصد ایجاد شدن، این فرایند رو نادیده بگیرید). در اصل برای یک فعالسازی موفق شما به دو فایل fullchain.pem و privkey.pem نیاز دارید. قبل از ادامه‌ی فرایند به دایرکتوری دلخواهی که این فایل‌ها رو در سرور مقصد (ایران اکسس) منتقل کردید برید و دسترسی‌های زیر رو برای این فایل‌ها فعال کنید! حالا نوبت می‌رسه به این‌که اگر certbot و Automatic renew برای اون سایت‌ها فعال بوده اون‌ها رو حذف کنید. به‌طور کلی شما با استفاده از دستور certbot certificates می‌تونید سرتیفیکیت‌های فعالی که توسط certbot در حال مدیریت هستند رو ببینید. یکی از مزیت‌هایی که سرتبات داره اینه که فرایند اخذ و یا تمدید گواهی در اون بسیار ساده است و حتی شما می‌تونید با قرار دادن کامندهای مربوط به renew در cronjobs این فرایند رو خودکار کنید، اما فراموش نکنید که ما الان در شرایطی هستیم که روی سرور مقصد خودمون امکان استفاده‌ی مستقیم از سرتبات و قابلیت‌هاش رو نداریم پس باید برای سایت مدنظر خودمون که گواهیش منقضی شده غیرفعالش کنیم.

chmod 600 privkey.pem
chmod 644 fullchain.pem cert.pem chain.pem
chown root:root *.pem

تا این مرحله شما تونستید فایل‌های مهم رو به سرور خودتون منتقل کنید. برای مراحل مربوط به استفاده از این فایل‌ها در وب‌سرور خودتون یا توضیحات بیشتر می‌تونید به مقاله‌ی اصلی مراجعه کنید! https://x.com/eferbarn/status/2050988420231782543 💚 Website | @hedgio_fa x @soliditylang_fa

در این مقاله بررسی شده که چه‌طور از چالش DNS-01 به‌جای HTTP-01 استفاده کنیم تا ثابت کنیم مالک دامنه هستیم تا بتونیم فایل‌های مربوط رو دریافت کنیم و به سرور ایران‌اکسس خودمون منتقل کنیم! بخش یک

برای تمدید سرتیفیکیت دامنه‌های خودتون چه به‌صورت single domain یا wildcard ، پیش روی شما ابزار کاربردی certbot قرار داره که به‌صورت پیش‌فرض می‌تونه سرتیفیکت‌های ۹۰ روزه از let's encrypt بگیره و فعال کنه. پروایدرهای دیگه‌ای هم مثل ZeroSSL از این مسیر قابل دستیابی هستند. در هر حال با استفاده از CLI مربوط به certbot شما وارد یک چلنج میشید که ثابت کنید مالک اون دامنه‌ای هستید که در حال درخواست سرتیفیکیت برای اون هستید. پیش روی شما گزینه‌های مختلفی از جلمه موارد زیر وجود داره:

* HTTP-01 Challenge (The common challenge) * DNS-01 Challenge * TLS-ALPN-01 Challenge

در حالت عادی certbot مستقیم به سراغ روش HTTP میره که در اون تعدادی فایل باید به صورت پابلیک روی سرور شما در دسترس باشن تا مرجع صادرکننده از بیرون اون‌ها رو ببینه و مالکیت دامنه‌ها رو تایید کنه. وقتی از کامندلاین استفاده کنید این فرایند بدون دردسر اضافه و به صورت خودکار انجام میشه. گاهی ممکنه دچار مشکلاتی در انجام این روش بشید (مثل شرایط فعلی ما) که مجبور بشید چالش‌های دیگری رو برای اثبات مالکیت دامنه قبول بکنید که یکی از فراگیرترین روش‌ها روش DNS-01 هست که شما در اون با قرار دادن یک سری ریکورد DNS در بخش Zone Editor محل کنترل دامنه‌ی خودتون ثابت می‌کنید مالک دامنه هستید. از اون‌جایی که در حال حاضر اکثر پرووایدرهای فعلی توانایی این رو دارن که ریکوردهای شما رو Propagate و عمومی بکنن، پس مرجع صادرکننده هم این توانایی رو داره که این ریکوردها رو از خارج از ایران ببینه! خوبی این روش اینه که روی یک ماشین دیگه هم قابل انجامه یعنی شما می‌تونید روی یک سرور/ماشین دیگه فایل‌ها رو درخواست داده و بعد به سرور مقصد بفرستید. توجه داشته باشید که تو همین مرحله می‌تونید تمام دامنه‌های مد نظر خودتون رو وارد بکنید. بهتره که حتماً URL مقادیر رو با www هم وارد کرده باشید. برای توضیح بیشتر باید گفت که اون manual نشون میده که شما دنبال تمدید اتوماتیک نیستید و اون preferred challenges هم نشون میده که شما دنبال چه چالشی هستید که در این‌جا dns یا همون dns-01 ذکر شده است. همچنین فلگ‌های مربوط به key-type یا elliptic-curve هم الگوریتم امضای دیجیتال شما رو تعیین می‌کنن. به صورت پیش‌فرض سرتبات در این روش به سراغ ECDSA و الیپتیک کرو secp256r1 (P-256) خواهد رفت، اما شما می‌تونید از کامبینیشن‌های مختلف حاصل از RSA, ECDSA و ... استفاده کنید. البته دقت کنید که مقدار پیش‌فرض certbt در این موضوع یکی از بهینه‌ترین الگوریتم‌های ساخت امضای دیجیتال برای وبسایت‌های عادی محسوب میشه. برای شروع درخواست این چالش کافیه کامند زیر رو در CLI خودتون وارد کنید تا چالش رو دریافت کنید:

sudo certbot certonly --manual --preferred-challenges dns \
    -d example.com \
    -d www.example.com \
    --key-type ecdsa \
    --elliptic-curve secp384r1 \
    -v

بعد از وارد کردن این درخواست برای شما ریکوردهایی که باید در DNS Zone Editor وارد کنید نمایش داده میشه که باید اون‌ها رو در تنظیمات دامنه‌ی خودتون اعمال کنید. توی این مرحله نیازه بین چند ثانیه تا چند دقیقه و حتی بیشتر صبر کنید تا مقادیر به‌طورعمومی در دسترس باشن و به اصطلاح پروپگیت بشن. می‌تونید برای مطمئن شدن از این فرایند از ابزارهایی مثل dig یا nslookup استفاده کنید. همچنین ابزار آنلاینی هم از Google Admin Toolbox در این زمینه در دسترس هست. توجه داشته باشید بعد Propagate شدن این ریکوردها و پاس کردن چالش شما می‌تونید این ریکوردها رو از Zone مربوطه حذف کنید. بعد از پایان چالش certbot به شما ۴ فایل خواهد داد که در ادامه به اون‌ها اشاره می‌کنیم! این فایل‌ها روی سروری که درخواست رو فرستاده در آدرس زیر در دسترس هستند: /etc/letsencrypt/live/domain

/etc/letsencrypt/live/<domain>/
├── cert.pem
├── chain.pem
├── fullchain.pem
└── privkey.pem

💚 Website | @hedgio_fa x @soliditylang_fa

رمقی نمونده که جلسه بذاریم و حرف بزنیم، اینه که اگر قرار شد چیزی یاد بگیریم، همین‌جا می‌نویسیم و می‌شنویم ازتون. خیلی برامون عزیزید! بخش صفر توضیح برای پست بعد: یکی از بزرگ‌ترین معضلاتی که قطعی اینترنت برای خیلی از ماها ایجاد کرده اینه که تمدید گواهی وبسایت‌ها با اختلال بسیار جدی مواجه شده. از آسیب‌هایی که این موضوع می‌تونه در پی داشته باشه تا صبح میشه حرف زد، اما حماقت که پایانی نداره که بخواد این حرف‌ها رو بشنوه. با توجه به این‌که سرتیفیکیت‌های رایگان صادر شده توسط Let's Encrypt (که بسیار هم محبوب هست) ۹۰ روزه هست، در بهترین حالت همین‌روزها باید نگران این باشید که چه‌طور برای دوره‌ی بعدی تمدید گواهی دامنه‌های خودتون رو انجام بدید! 💚 Website | @hedgio_fa

پی‌نوشت: دلیل این‌که چرا تتر روی BNB-Chain روشی برای فریز دارایی شما هم نداره الان تقریباً واضحه دیگه. نیازی بهش نیست اصلاً! 💚 Website | @hedgio_fa

بعد از وقوع این ماجرا، اظهارنظرهای غیرتخصصی زیادی مطرح شد که یکی از اون‌ها نگه‌داری تتر روی شبکه‌ی BSC بود (با ذکر این دلیل که روی کانترکت تتر در این شبکه، متد فریز وجود نداره، که البته درست هم هست). بارها این رو مطرح کردیم که BNB-Chain یک شبکه‌ی PoSA محسوب میشه. درواقع Proof of Staked Authority یک مکانیزم میانی/هیبریدی بین PoS و PoA هست. یه‌جورایی هیچ‌کدوم این دوتا نیست و همزمان جفت این‌ها هست. حالا موضوع اینه که هر زمان اون ساید Authority اراده کنه (که از قضا به‌شدت هم متمرکز هستن در این کیس)، دیگه فرقی نمی‌کنه شما بخواید برای تتر تراکنش بزنید یا هرچیز دیگری. هیچ تراکنشی از سمت آدرس شما توی شبکه پذیرفته نخواهد شد. اینه که آدرس شما تبدیل میشه به زباله‌دانی از توکن‌های مختلف من‌جمله تتر و همچنین خود گس شبکه. به‌عنوان یک قاعده‌ی کلی اگر برای آرامش خاطر خودتون احترام قائل هستید از تتر و بعد از اون از BNB-Chain دوری کنید! 💚 Website @hedgio_fa