چگونه بدهی بد Aave کار می‌کند: از باقی‌مانده‌های پس از تصفیه تا کسری ذخیره

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

نکات کلیدی

• بدهی بد آوه یک حالت خاص پس از تصفیه است که در آن یک حساب هیچ وثیقه‌ای ندارد اما هنوز بدهی باقی‌مانده دارد.آوه v3.3 از انباشت بدهی‌های "زامبی" جلوگیری می‌کند با سوزاندن توکن‌های بدهی متغیر باقی‌مانده و ثبت کسری به عنوان کسری به ازای ذخیره.کسری‌ها به ازای هر دارایی در ReserveData پیگیری می‌شوند و از طریق یک دریافت‌کننده استخر در دسترس قرار می‌گیرند، که باعث می‌شود ضررها قابل اندازه‌گیری باشند به جای اینکه به طور نامرئی سرگردان شوند.کسری‌ها می‌توانند توسط یک نهاد مجاز چتر با سوزاندن aTokens کاهش یابند و استیکینگ چتر به گونه‌ای طراحی شده است که خزانه‌های خاص دارایی را پس از عبور بدهی بد از آستانه‌ها کاهش دهد.بدهی بد در آوه به چه معناست (تعریف به زبان ساده)
• چگونه بدهی بد آوه کار می‌کند با یک تعریف دقیق شروع می‌شود، نه یک حس. در آوه، بدهی بد نه "یک وام‌گیرنده پرخطر" است و نه "یک تصفیه که اشتباه پیش رفت." این یک حالت نهایی حسابداری پس از تصفیه است که در آن وثیقه وام‌گیرنده به طور کامل مصرف شده و برخی از بدهی‌ها پرداخت نشده باقی مانده‌اند. در آن نقطه، پروتکل یک بدهی بدون پوشش را در دست دارد.
• این موضوع مهم است زیرا آوه یک پروتکل وام‌دهی "بیش از وثیقه" به طور طراحی شده است. کل فرض این است که ارزش وثیقه باید به اندازه کافی برای پوشش بدهی از طریق تصفیه دیفای زمانی که یک موقعیت ناسالم می‌شود، کافی باشد.
• بدهی بد چیزی است که باقی می‌ماند زمانی که آن مکانیزم نمی‌تواند به طور کامل حلقه را به دلیل شکاف‌های قیمتی، محدودیت‌های نقدینگی یا سرعت تصفیه ببندد.مستندات آوه v3 به صراحت به حالت لبه ناراحت‌کننده اشاره می‌کند: برخی از سناریوهای تصفیه می‌توانند با وثیقه صفر و بدهی باقی‌مانده به پایان برسند و احتمالاً آن بدهی پرداخت نخواهد شد. مشکل عملی نه تنها از دست دادن است. بلکه انحراف است. اگر سیستم به درمان آن باقی‌مانده به عنوان بدهی متغیر عادی ادامه دهد، بهره بر روی یک IOU که هیچ وثیقه‌ای پشت آن نیست، انباشته می‌شود و بدهی ظاهری پروتکل را در طول زمان افزایش می‌دهد. این حالت شکست "بدهی بد دیفای" است که معامله‌گران باید واقعاً به آن اهمیت دهند.چگونه بدهی بد آوه کار می‌کند
• در عمل، چگونه بدهی بد آوه کار می‌کند یک توالی ورودی‌ها → فرآیند → خروجی‌ها است.

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

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

آوه v3 یک عامل بسته متغیر معرفی کرد که می‌تواند تا 100% پرداخت را تحت شرایط اضطراری عمیق‌تر مجاز کند، که به کاهش "غبار" باقی‌مانده که به تصفیه اقتصادی نمی‌رسد، کمک می‌کند.

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

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

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

راهنمای Bitget مکانیک‌های اصلی را به تصویر می‌کشد: تصفیه زمانی آغاز می‌شود که عامل سلامت زیر آستانه می‌افتد و تصفیه‌کنندگان بدهی را در ازای وثیقه با تخفیف پرداخت می‌کنند. همچنین به تفاوت عامل بسته در نسخه‌ها اشاره می‌کند، با آوه v2 که تا 50% پرداخت در هر تصفیه را مجاز می‌داند و آوه v3 که تا 100% پرداخت را در زمانی که عامل سلامت بیشتر کاهش می‌یابد، مجاز می‌داند (یک آستانه مثال حدود 0.95 ذکر شده است).

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

مستندات آوه v3.3 به وضوح به حالت لبه اشاره می‌کند: تصفیه می‌تواند منجر به این شود که کل وثیقه تصفیه شده برای پوشش پرداخت تمام بدهی کافی نباشد و وثیقه صفر و بدهی باقی‌مانده بگذارد. این لحظه‌ای است که مشکل وام‌گیرنده به یک مشکل حسابداری پروتکل تبدیل می‌شود.

مدیریت بدهی بد آوه v3.3: سوزاندن بدهی باقی‌مانده وام‌گیرنده، ثبت یک کسری ذخیرهتغییر کلیدی آوه v3.3 "جلوگیری از بدهی بد" نیست. بلکه "متوقف کردن تغییر بدهی بد" است. پروتکل یک مرحله تأیید پس از تصفیه را معرفی می‌کند که به منظور کاهش ایجاد حساب‌های بدهی بد جدید پس از تصفیه و متوقف کردن انباشته شدن بیشتر بهره بر روی آن بدهی‌ها طراحی شده است.به طور مکانیکی، پروتکل حساب را پس از تصفیه و پرداخت بررسی می‌کند.

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

این پایان‌نامه v3.3 به شکل کد است: بدهی بد دیگر اجازه ندارد بر روی یک کاربر بنشیند و برای همیشه انباشته شود. این به یک کسری در سطح ذخیره بلورین می‌شود که می‌توان آن را به ازای هر دارایی پیگیری کرد. v3.3 پیگیری کسری را در داخل ReserveData با استفاده مجدد از ذخیره‌سازی stableBorrowRate منسوخ شده معرفی می‌کند و آن را از طریق یک دریافت‌کننده استخر getReserveDeficit در دسترس قرار می‌دهد.

این باعث می‌شود که حفره قابل نشانه‌گذاری باشد، ذخیره به ذخیره، به جای اینکه در ریاضیات بهره سرگردان دفن شود.همچنین برای GHO مدیریت ویژه‌ای وجود دارد. v3.3 تصفیه را به یک سوزاندن بدهی متغیر و یک پردازش‌کننده پرداخت aGHO که هزینه‌ها را تخفیف می‌دهد، تقسیم می‌کند. هنگام سوزاندن بدهی بد در GHO، پروتکل ذخیره‌سازی هزینه‌های انباشته را در vGHO بازنشانی می‌کند و به طور مؤثر ضرر را بر روی هزینه‌های انباشته برای بخش بدهی بد می‌پذیرد تا حسابداری را سازگار نگه دارد. این جزئیات مهم است زیرا نشان‌دهنده نیت است. هدف پاکسازی قطعی است، نه اینکه ادعاهای هزینه‌های کهنه را به حسابی که دیگر توکن‌های بدهی ندارد، متصل کند.چگونه ماژول ایمنی آوه کار می‌کندماژول ایمنی قدیمی بهترین است که به عنوان یک پشتیبان مدیریت شده توسط حاکمیت درک شود نه یک موتور بیمه همیشه فعال. Blockworks آن را به عنوان یک پشتیبان توصیف می‌کند که در نظریه می‌تواند stkAAVE و موقعیت‌های LP AAVE-ETH را کاهش دهد، اما "کاهش" هرگز اتفاق نیفتاد زیرا به رأی‌گیری حاکمیتی نیاز داشت و انگیزه‌های سیاسی فعال‌سازی را غیرمحتمل می‌کرد.از نظر ریسک عملی، این بدان معناست که ارزش ماژول ایمنی اعتبار بود، نه اتوماسیون. این نشان می‌دهد که یک گروه هم‌راستا با توکن حاکمیتی می‌تواند ضررها را بازسازی کند، اما تضمینی برای جذب سریع و قطعی ضرر در یک بازار سریع وجود ندارد.

این دلیل است که حسابداری بدهی بد v3.3 حتی اگر یک پشتیبان وجود داشته باشد، مهم است. اگر بدهی بد اجازه داشته باشد که بر روی حساب‌های کاربر باقی بماند و بهره انباشته شود، پروتکل حتی نمی‌تواند ضرر را به طور تمیز اندازه‌گیری کند، که تصمیم‌گیری در مورد هر پشتیبانی را دشوارتر می‌کند. با تبدیل کسری به یک کسری ذخیره، آوه سوال ماژول ایمنی را ملموس‌تر می‌کند: چه مقدار کسری وجود دارد، بر روی کدام دارایی و چه مکانیزمی مجاز به خنثی کردن آن است.

چه کسی پرداخت می‌کند وقتی آوه بدهی بد دارد

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

این چارچوب پاسخ می‌دهد که در عمل چه کسی پرداخت می‌کند: ذخیره کم است و سیستم نیاز به تجدید سرمایه‌گذاری دارد تا پشتیبانی کامل را بازگرداند. نسخه 3.3 تابع eliminateReserveDeficit را معرفی می‌کند، جایی که یک نهاد مجاز، Umbrella ثبت شده در PoolAddressesProvider، می‌تواند aTokens را بسوزاند تا کسری آن ذخیره را کاهش دهد. این تابع محدود به سوزاندن تا کسری موجود است و تأیید می‌کند که تماس‌گیرنده هیچ موقعیت وام باز ندارد.

این یک اقدام مبهم «ممکن است صندوق بیمه آن را پوشش دهد» نیست. این یک اقدام خاص زنجیره‌ای است که کسری ردیابی شده را با نابود کردن ادعاها بر روی ذخیره (aTokens) کاهش می‌دهد. پیامد اقتصادی واضح است.

کسی که دارایی‌های پوشش‌دهنده را در اختیار دارد، ضربه را متحمل می‌شود تا سپرده‌گذاران در آن ذخیره دوباره به حالت اولیه برگردند.توصیف Blockworks از استیکینگ Umbrella لایه عملیاتی را اضافه می‌کند. Umbrella به عنوان یک شبکه ایمنی خودکار که به دارایی‌های فردی متصل است، ارائه می‌شود، با کاهش آنی زمانی که بدهی بد در آن دارایی از یک آستانه از پیش تعیین شده فراتر رود، پس از یک جبران اولیه قابل تنظیم که در آن زمان به عنوان 100,000 واحد به ازای هر دارایی گزارش شده بود. این پاسخ عملی به «چه کسی پرداخت می‌کند» در یک سیستم طراحی شده است: استیکرها در خزانه دارایی تحت تأثیر، بالای بافر جبران، به جای یک استخر عمومی که نیاز به رأی‌گیری حکومتی دارد.آیا Aave قبلاً بدهی بد داشته است؟

بله، و رویداد CRV در سال 2022 تمیزترین تصویر از این است که چرا «فقط آن را تصفیه کنید» تضمینی نیست. مطالعه موردی EigenPhi یک موقعیت کوتاه CRV را توصیف می‌کند که منجر به حدود 2.456 میلیون CRV پرداخت نشده پس از تصفیه‌ها شد که در قیمت ذکر شده CRV حدود 1.6 میلیون دلار ارزش داشت.

فعالیت تصفیه trivial نبود. EigenPhi گزارش می‌دهد که 385 تصفیه توسط 21 آدرس منحصر به فرد انجام شده است. نکته این نیست که تصفیه‌کنندگان غایب بودند. نکته این است که توان تصفیه و زمان‌بندی اوراکل هنوز می‌تواند یک باقی‌مانده بدهی را زمانی که بازارها به صورت جهشی حرکت می‌کنند، باقی بگذارد.

EigenPhi همچنین به تأخیر قیمت اوراکل حدود 10 دقیقه در مقابل Binance اشاره می‌کند و رفتار تصفیه‌ای را توصیف می‌کند که به صورت دسته‌ای انجام می‌شود. این ترکیب دقیقاً محیطی است که در آن وثیقه می‌تواند قبل از اینکه بدهی به طور کامل پرداخت شود، تمام شود. تعریف بدهی بد در Aave v3.3 به عنوان «وثیقه‌ای که قبل از پرداخت کامل بدهی تمام شده» نظری نیست. این وضعیتی است که قبلاً تحت فشار اتفاق افتاده است.

ماژول Umbrella Aave چیست؟

Umbrella طراحی ایمنی جدیدتر Aave است که سعی می‌کند جذب ضرر را هم خودکار و هم خاص دارایی کند. Blockworks استیکینگ Umbrella را به عنوان یک شبکه ایمنی خودکار زنجیره‌ای که به طور مستقیم به دارایی‌های فردی متصل است، توصیف می‌کند که به عنوان خزانه‌های ایزوله پیاده‌سازی شده است. اگر کمبود رخ دهد، پروتکل می‌تواند همان دارایی را از خزانه خود پس از یک جبران اولیه قابل تنظیم بسوزاند که در آن زمان به عنوان 100,000 واحد به ازای هر دارایی گزارش شده بود.

قسمت «خاص دارایی» تغییر واقعی طراحی است. به جای اجتماعی کردن ریسک در یک پشتوانه توکن حکومتی وسیع، Umbrella به ذخیره‌ای که واقعاً کسری دارد، هدف‌گذاری می‌کند. این با ردیابی کسری به ازای هر ذخیره در نسخه 3.3 هم‌راستا است. اگر پروتکل بتواند کسری را در USDC در مقابل ETH در مقابل GHO اندازه‌گیری کند، یک پشتوانه که همچنین بر اساس دارایی تقسیم‌بندی شده است، از نظر عملی تمیزتر است.

Umbrella همچنین بعد زمانی را تغییر می‌دهد. Blockworks تأکید می‌کند که هیچ رأی‌گیری حکومتی، هیچ حراج و هیچ تأخیری برای کاهش زمانی که آستانه‌ها شکسته می‌شوند وجود ندارد. این مهم است زیرا بدهی بد معمولاً در بازارهای سریع متولد می‌شود. یک پشتوانه که تنها پس از یک فرآیند طولانی حکومتی فعال می‌شود، به طور ساختاری با مشکل همخوانی ندارد.

آیا Aave می‌تواند ورشکسته شود؟Aave می‌تواند در سطح ذخیره با زمانی که بدهی‌ها از دارایی‌ها برای یک بازار خاص فراتر می‌روند، با ورشکستگی مواجه شود که دقیقاً همان چیزی است که یک کسری ذخیره نمایان می‌کند. Aave v3.3 به گونه‌ای دیگر وانمود نمی‌کند. این کسری را رسمی می‌کند تا بتوان آن را ردیابی و احتمالاً خنثی کرد.نکته کلیدی در اینجا دامنه است.

نسخه 3.3 یک وضعیت بدهی بد را به طور باریک به عنوان یک حساب با وثیقه صفر در ارز پایه و بدهی باقی‌مانده در ارز پایه تعریف می‌کند. حساب‌هایی که هرگونه وثیقه باقی‌مانده دارند به عنوان بدهی بد در نظر گرفته نمی‌شوند زیرا ممکن است دوباره بیش از حد وثیقه‌گذاری شوند. این یک خط عملی است.

ورشکستگی مربوط به بدهی‌های بدون پشتوانه است، نه موقعیت‌های موقتی ناسالم.نسخه 3.3 همچنین محدودیت‌هایی را مستند می‌کند که برای هر کسی که ریسک دمی را مدل‌سازی می‌کند، مهم است. این نسخه موقعیت‌های بدهی بد موجود را اصلاح نمی‌کند و پاکسازی DAO را از طریق repayOnBehalf توصیه می‌کند. حذف کسری فرض می‌کند که Umbrella توکن‌هایی برای سوزاندن دارد و محدودیت‌های عملی مانند سقف‌ها و حسابداری مجازی می‌تواند بر سرعتی که دارایی‌های پوشش‌دهنده می‌توانند قرار بگیرند تأثیر بگذارد. این بدان معناست که سیستم می‌تواند شناسایی کند و از انباشت بدهی زامبی جدید جلوگیری کند، اما تجدید سرمایه‌گذاری هنوز به پیکربندی پشتوانه و پوشش موجود وابسته است.مفاهیم غلط رایج

مفهوم غلط اول این است که «بدهی بد به معنای این است که تصفیه‌ها شکست خورده‌اند.» تصفیه‌ها می‌توانند دقیقاً طبق طراحی اجرا شوند و هنوز هم با وثیقه صفر و بدهی باقی‌مانده به پایان برسند زیرا طراحی تحت تأثیر عوامل نزدیک، اقتصاد گاز، سرعت به‌روزرسانی اوراکل و نقدینگی بازار ثانویه محدود است. مطالعه موردی CRV نشان می‌دهد که فعالیت تصفیه سنگین بوده و هنوز هم یک مبلغ پرداخت نشده باقی مانده است.

مفهوم غلط دوم این است که «بدهی بد فقط یک وام پرداخت نشده وام‌گیرنده است.» در Aave v3.3، زمانی که پروتکل توکن‌های بدهی متغیر باقی‌مانده وام‌گیرنده را می‌سوزاند، وام‌گیرنده دیگر جایی نیست که بدهی در آن وجود داشته باشد. این ضرر به عنوان یک کسری ذخیره، به ازای هر دارایی، ثبت می‌شود و سؤال این است که چگونه این کسری از طریق مکانیزم‌هایی مانند eliminateReserveDeficit و کاهش خزانه دارایی Umbrella کاهش می‌یابد.

مفهوم غلط سوم این است که «Aave v3.3 تمام بدهی‌های بد را حذف می‌کند.» نسخه 3.3 از انباشت بهره در حساب‌های زامبی جدید پس از تصفیه جلوگیری می‌کند با سوزاندن بدهی باقی‌مانده و ثبت یک کسری، اما مستندات به وضوح بیان می‌کند که این نسخه موقعیت‌های بدهی بد موجود را حل نمی‌کند. نتیجه عملی این است که نسخه 3.3 قضاوت و شفافیت را بهبود می‌بخشد، نه قوانین گپ‌های بازار.

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

منابع

Aave DAO (مستندات Aave v3.3)

Blockworks

EigenPhi

Bitget Academy

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop