معماری پولکادات ۳.۰ (JAM) و اجرای شاردینگ

۱. پیشنیازها در ادامه، مفاهیم زیر مورد استفاده قرار میگیرند و درک آنها پیشفرض است. تابع تغییر وضعیت به عنوان بلاکچین (State Transition Function) درک «وضعیت» (State) هر دو مفهوم در اینجا توضیح داده شدهاند. امنیت اقتصادی و اثبات سهام (Proof of Stake) محتوای مربوطه در سخنرانیهای PBA و ویدئوها توضیح داده شده است.

۲. مقدمه: پولکادات ۱.۰ اول، ویژگیهای نوآورانهترین پولکادات ۱.۰ به شرح زیر خلاصه میشود: جنبه اجتماعی: پولکادات را میتوان از هر نظر به عنوان یک DAO بزرگ دید. حاکمیت شبکه، از جمله ارتقای رانتایم بدون فورک (fork-less)، کاملاً روی زنجیره و به صورت خودکار انجام میشود. کمیسیون بورس و اوراق بهادار آمریکا (SEC) DOT را نرمافزار میداند، نه اوراق بهادار. اکثر توسعه شبکه توسط همگرایی پولکادات (Polkadot Fellowship) انجام میشود، نه شرکتهای حسابداری (مانند پاریتی). جنبه فنی: اشتراکگذاری امنیت و اجرای شاردینگ (تکنیکی که دادههای شبکه بلاکچین را به «شارد» تقسیم میکند). استفاده از متاپروتکل مبتنی بر WASM. با ذخیره کد بلاکچین به شکل بایتکد در وضعیت، اکثر ارتقاها را میتوان بدون فورک انجام داد که این امر شاردینگ ناهمگن را در پولکادات ممکن میسازد. برای جزئیات بیشتر به ناهمگونی مراجعه کنید. اکنون اجرای شاردینگ را با جزئیات بیشتری بررسی میکنیم.

۳. هسته اصلی در اجرای شاردینگ در این مقاله، شبکههای L1 که میزبان بلاکچینهای L2 دیگر مانند پولکادات یا اتریوم هستند، مورد بحث قرار میگیرند. از این رو، L2 و پاراچین (Parachain) به عنوان مترادف در نظر گرفته میشوند. مسئله اصلی مقیاسپذیری بلاکچین را میتوان به صورت زیر خلاصه کرد: گروهی از اعتبارسنجها وجود دارند و کدی که اجرا میکنند از طریق مفهوم رمزاقتصادی اثبات سهام تضمین اعتبار دارد. اعتبارسنجها اساساً باید کل کار یکدیگر را دوباره اجرا کنند. به عبارت دیگر، این سیستم تا زمانی که همه اعتبارسنجها را مجبور کند همیشه همه چیز را (دوباره) اجرا کنند، مقیاسپذیر نخواهد بود. توجه داشته باشید که تا زمانی که اصل اجرای مجدد ذکر شده در بالا حفظ شود، افزایش تعداد اعتبارسنجها در این مدل لزوماً منجر به افزایش توان عملیاتی سیستم نمیشود. توضیحات بالا ویژگیهای بلاکچینهای یکپارچه (monolithic) را توصیف میکند که در تضاد با شاردینگ است. ورودیها (مانند بلاک) به صورت تکتک توسط تمام اعتبارسنجهای شبکه پردازش میشوند. اگر چنین سیستمی بخواهد میزبان L2های بیشتری باشد، همه اعتبارسنجها باید کار تمام L2ها را دوباره اجرا کنند. طبیعتاً نمیتوان در چنین سیستمی انتظار مقیاسپذیری داشت. راهی برای دور زدن این مشکل، رولآپهای خوشبینانه (Optimistic) است که اجرای مجدد (که به آن اثبات کلاهبرداری یا fraud proof میگویند) تنها زمانی رخ دهد که کسی ادعا کند کلاهبرداری شده است. رولآپهای مبتنی بر SNARK بر این واقعیت استوار است که تأیید شواهد SNARK بسیار ارزانتر از تولید آن است، بنابراین به همه اعتبارسنجها اجازه میدهد شواهد SNARK را تأیید کنند. برای جزئیات بیشتر به نقشه مقیاسپذیری در پیوست مراجعه کنید. راه حل ساده شاردینگ این است که گروه اعتبارسنجها را به زیرمجموعههای کوچکتر تقسیم کنیم و این زیرمجموعه کوچکتر بلاک L2 را دوباره اجرا کند. چه مشکلی در این رویکرد وجود دارد؟ اینکه در حال شاردینگ اجرا و امنیت اقتصادی شبکه هستیم. امنیت L2 در برابر L1 از قبل ضعیف است و هرچه گروه اعتبارسنجها را به شاردهای بیشتری تکهتکه کنیم، امنیت بیشتر تضعیف میشود. برخلاف رولآپهای خوشبینانه که نمیتوانند هر بار تراکنش را دوباره اجرا کنند، پولکادات برای شاردینگ تراکنشها طراحی شده است. این کار امکان دوباره اجرای بلاکهای L2 را توسط زیرمجموعههای اعتبارسنج فراهم میکند و به همه شرکتکنندگان شبکه شواهد رمزاقتصادی میدهد که درستی بلاک L2 به اندازه دوباره اجرای آن توسط کل گروه اعتبارسنجان امن است. این کار از طریق مکانیزم ELVES که اخیراً رسمی شده، ممکن میشود. ELVES را میتوان نوعی مکانیزم «رولآپ بدبینانه (Cynical Rollup)» در نظر گرفت. فرآیندی که در آن اعتبارسنجها چندین بار تأیید اعتبار بلاک L2 را از سایر اعتبارسنجها دریافت میکنند و تشخیص میدهند که احتمال اعتبار بلاک L2 بالاست. در صورت بروز اختلاف، کل گروه اعتبارسنجان در مدت کوتاهی دعوت به مشارکت میشوند، که این مطلب در نوشته راب هابرمایر، یکی از بنیانگذاران مشترک پولکادات، به خوبی توضیح داده شده است. اینکه پولکادات بتواند هر دو ویژگی «اجرای شاردینگ» و «امنیت اشتراکی» را داشته باشد که معمولاً متقابل انحصاری (mutually exclusive) در نظر گرفته میشوند، به لطف مکانیزم ELVES است و این دستاورد فنی اصلی پولکادات ۱.۰ در مقیاسپذیری نیز هست. اکنون به استعاره «هسته» میپردازیم. بلاکچین با اجرای شاردینگ (execution-sharded) را میتوان به پردازنده (CPU) تشبیه کرد. درستمانند CPU که دارای هستههای متعددی برای پردازش موازی دستورات است، پولکادات نیز میتواند بلاکهای L2 را به صورت موازی پردازش کند. به همین دلیل، در پولکادات L2 را پاراچین (Parachain)[۱] و محیطی که زیرمجموعهای از اعتبارسنجها یک بلاک L2 واحد را اجرا میکنند، «هسته» مینامند. هر هسته را میتوان به عنوان «گروهی همکاریکننده از اعتبارسنجان» خلاصه کرد. در حالی که بلاکچین یکپارچه میتواند تنها یک بلاک را در هر بازه زمانی پردازش کند، پولکادات میتواند یک بلاک زنجیره رله و یک بلاک پاراچین برای هر هسته و بازه زمانی پردازش کند.

۳.۱. ناهمگونی تا اینجا فقط در مورد مقیاسپذیری و اجرای شاردینگ پولکادات صحبت کردیم، اما یک نکته مهم این است که هر شارد در پولکادات یک کاربرد کاملاً مجزا است[۲]. این کار با استفاده از متاپروتکلی که به صورت بایتکد ذخیره میشود، پیادهسازی شده است. متاپروتکول پروتکلی است که در آن تعریف بلاکچین به شکل بایتکد در وضعیت بلاکچین ذخیره میشود. در پولکادات ۱.۰ از WASM به عنوان بایتکد استفاده شد و در JAM از PVM/RISC-V استفاده میشود. در نهایت، این دلیل نامیده شدن پولکادات به عنوان بلاکچین شاردینگ ناهمگن (heterogeneous sharded blockchain) است. هر L2 را میتوان کاربردی کاملاً متفاوت و جداگانه در نظر گرفت.

۴. پولکادات ۲.۰ تمرکز پولکادات ۲.۰ بر این است که استفاده از هستهها را انعطافپذیرتر کند. در مدل سنتی پولکادات، یک هسته را میتوان به مدت ۶ ماه تا ۲ سال اجاره کرد. این مدل برای کسبوکارهایی با منابع فراوان مناسب است، اما برای تیمهای کوچک نه. قابلیتی که استفاده از هستههای پولکادات را انعطافپذیرتر میکند، «زمان هسته چابک (agile coretime)» نام دارد، که در آن میتوان هسته پولکادات را از یک بلاک تا حداکثر یک ماه اجاره کرد و برای اجارههای طولانیمدت نیز سقف قیمت (price cap) تضمین میشود. در حال حاضر پولکادات ۲.۰ همراه با سایر قابلیتها در حال توسعه است، بنابراین در اینجا از توضیحات بیشتر خودداری میکنیم.

۵. داخل هسته در مقابل روی زنجیره برای درک JAM (Polkadot ۳.۰)، باید بفهمید وقتی یک بلاک L2 وارد میشود، چه اتفاقی در هسته پولکادات رخ میدهد. زیر محتوای بسیار سادهسازی شدهای آمده است: هسته اساساً از گروهی از اعتبارسنجان تشکیل شده است. «ارسال داده به هسته» به این معنی است که داده به گروه اعتبارسنجان تحویل داده شده است. ۰. یک بلاک L2 و زیرمجموعهای از وضعیت مربوطه آن L2 به هسته ارسال میشود. این تنها دادهای است که برای پردازش بلاک L2 لازم است[۳]. ۱. زیرمجموعهای از اعتبارسنجان که هسته را تشکیل میدهند، بلاک L2 را دوباره اجرا کرده و کارهای مربوط به اجماع را انجام میدهند. ۲. اعتبارسنجان هسته دادههای لازم را برای سایر اعتبارسنجان (خارج از هسته) فراهم میکنند تا بتوانند اجرای مجدد را انجام دهند. طبق قوانین ELVES، ممکن است اعتبارسنجان بیشتری بخواهند بلاک L2 را دوباره اجرا کنند و به این دادهها نیاز دارند. به خاطر داشته باشید که تمام این کارها جدا از تابع تغییر وضعیت و بلاک اصلی پولکادات و در خارج انجام میشود. تمام فرآیندهای توضیح داده شده تا اینجا در داخل هسته و لایه در دسترس بودن داده رخ میدهد. ۳. آخرین وضعیت ارسال شده توسط L2 در وضعیت زنجیره رله پولکادات ذخیره میشود. این کار بسیار ارزانتر از اجرای مجدد بلاک L2 است، بر وضعیت اصلی پولکادات تأثیر میگذارد، در بلاک پولکادات ثبت میشود و توسط تمام اعتبارسنجان پولکادات پردازش میشود. علاوه بر توضیحات بالا، بیایید بیشتر بررسی کنیم که پولکادات چه کارهایی انجام میدهد: در بخش ۱ متوجه شدیم که پولکادات روش پردازش متفاوتی نسبت به تابع تغییر وضعیت معمول بلاکچین دارد. به طور معمول، وقتی تمام اعتبارسنجان شبکه کار را اجرا میکنند، وضعیت بلاکچین اصلی بهروزرسانی میشود که به آن عملیات روی زنجیره (on-chain operation) میگویند. این کار مربوط به بخش ۳ است. اما کارهایی که در داخل هسته (بخش ۱) رخ میدهد متفاوت است. به این روش جدید محاسبات بلاکچین، پردازش درونهستهای (in-core execution) میگویند. از بخش ۲ میتوان نتیجه گرفت که پولکادات از قبل لایه در دسترس بودن داده (DA) بومی ارائه میدهد و L2 به طور خودکار این DA را برای مدت مشخصی به عنوان مدرک پردازش استفاده میکند. همچنین دادهای که میتواند روی این لایه DA[۴] قرار گیرد ثابت است و این داده همیشه مدرکی است که برای اجرای مجدد بلاک L2 لازم است. علاوه بر این، کد پاراچین نمیتواند داده را از لایه DA بخواند. این مطالب مبنای درک قابلیتهای JAM است. خلاصه به شرح زیر است: پردازش درونهستهای: در داخل هسته رخ میدهد. دارای منابع فراوان (abundance) و مقیاسپذیری است و بر اساس رمزاقتصاد و ELVES امنیتی معادل «پردازش روی زنجیره» دارد. پردازش روی زنجیره: کار اعتبارسنجان است. امنیت توسط اعتبارسنجان با انگیزه اقتصادی حفظ میشود و چون همه همه چیز را پردازش میکنند، گرانتر و محدودتر است. دسترسپذیری داده: ارائه دادههای قابل استفاده برای مدت مشخص توسط اعتبارسنجان پولکادات به سایر اعتبارسنجان است.

۶. JAM (Polkadot ۳.۰) اگر توضیحات قبلی را درک کرده باشید، مفهوم JAM راحتتر قابل درک است. JAM تحت تأثیر شدید پولکادات است، کاملاً با پولکادات سازگار است، یک پروتکل جدید است که قصد دارد زنجیره رله پولکادات را جایگزین کند و استفاده از هستهها را به طور بنیادی بیطرف (un-opinionated[۵]) کند. JAM بر پایه پولکادات ۲.۰ است. هدف این است که کاربری هستههای پولکادات را به روشی بنیادیتر و انعطافپذیرتر و بیطرفتر از زمان هسته چابک افزایش دهد. در پولکادات ۲.۰، تخصیص هسته برای L2ها سیالتر است. هسته اصلی JAM این است که هرگونه کاربردی، نه صرفاً بلاکچین یا L2، را بتوان روی هسته پولکادات مستقر کرد. دلیل اصلی امکانپذیری بودن این کار، ارائه سه عنصر توضیح داده شده در بخش قبلی یعنی پردازش درونهستهای و روی زنجیره، و دسترسپذیری داده به توسعهدهندگان است. به بیان دیگر، JAM قابلیتهای زیر را به توسعهدهندگان میدهد: میتوان کارهایی را که در داخل هسته و روی زنجیره انجام میشود برنامهنویسی کرد. میتوان دادههای دلخواه را از لایه DA پولکادات خواند و وارد کرد. تا اینجا با محتوای کلی جهتگیری JAM آشنا شدیم. البته بسیاری از موارد ساده شدهاند و پروتکل در حال توسعه است. بر اساس توضیحات تا اینجا، جزئیات بیشتری از JAM را بررسی میکنیم.

۶.۱. سرویسها و آیتمهای کاری در سیستم JAM، آنچه قبلاً L2/Parachain نامیده میشد، سرویس (Service) و بلاک/تراکنش، آیتم کاری (Work-Item) یا بسته کاری (Work-Package) نامیده میشود. به عبارت دیگر، آیتم کاری متعلق به سرویس است و بسته کاری به گروهی از آیتمهای کاری گفته میشود. هر دو واژه برای پوشش موارد استفاده که محدود به بلاکچین/L2 نیستند، به عنوان اصطلاحات عمومی انتخاب شدهاند. سرویس را میتوان با سه نقطه ورودی توصیف کرد که دو مورد از آنها fn refine() و fn accumulate()[۶] هستند. اولی کارهایی را که سرویس درونهستهای انجام میدهد توصیف میکند و دومی کارهایی را که سرویس روی زنجیره انجام میدهد توصیف میکند. در نهایت، نام دو نقطه ورودی به نام پروتکل یعنی JAM (ماشین تجمیع و اتصال - Join Accumulate Machine) مرتبط است. Join به fn refine() مربوط میشود، جایی که تمام هستههای پولکادات به صورت موازی کار زیادی را برای سرویسهای مختلف انجام میدهند. در Join، دادهها به زیرمجموعههای کوچکتر تصفیه و به مرحله بعد منتقل میشوند. Accumulate جایی است که نتیجه فرآیند قبلی در وضعیت اصلی JAM جمع میشود که مربوط به اجرای روی زنجیره است. 💡 آیتم کاری میتواند به طور مشخص تعیین کند که چه کدی را در هسته و روی زنجیره اجرا کند، و همچنین نحوه، محتوا و اینکه آیا دادههای دریاچه داده توزیع شده (Distributed Data Lake) را میخواند یا مینویسد را مشخص میکند.

۶.۲. نیمهثبات طبق منابع موجود در مورد XCM که زبان ارتباطی بین پاراچینهای پولکادات است، تمام ارتباطات غیرهمگام (asynchronous) هستند.

به عبارت دیگر، پس از ارسال پیام، منتظر پاسخ نمیماند. عدم همگامی (Asynchrony) ویژگی سیستمهای ناهماهنگ است و مسئلهای اصلی در سیستمهایی است که شاردینگ دائمی در آنها پیادهسازی شده است، مانند پولکادات ۱.۰، پولکادات ۲.۰ و گروه موجود لایه دوم اتریوم. اما همانگونه که در بخش ۲.۴ کاغذ خاکستری توضیح داده شد، سیستمی که برای همه اعضا همیشه همگام و کاملاً هماهنگ باشد، بدون فدا کردن عمومیت (generality)، دسترسیپذیری (accessibility) و تابآوری (resilience) رشد نخواهد کرد. ℹ️همگامی (Synchronous) ~ هماهنگی (Coherent) || عدم همگامی (Asynchronous) ~ ناهماهنگی (Incoherent) این حوزهای است که قدرت JAM دوباره میدرخشد. JAM با معرفی ویژگیهای مختلف (property) نقطه تعادلی نوآورانه به نام سیستم نیمههماهنگ (semi-coherent system) را یافته است. یعنی به زیرسیستمهایی که اغلب با هم ارتباط برقرار میکنند فرصت داده میشود تا محیطی هماهنگ ایجاد کنند، اما این امر بر کل سیستم تحمیل نمیشود. این موضوع در مصاحبه دکتر گوین وود، نویسنده کاغذ خاکستری، به تفصیل بررسی شده است. دیدگاه دیگر این است که پولکادات و JAM را به عنوان یک سیستم شاردینگ ببینیم که مرزهای شاردها سیال و در هر لحظه تعیین میشود. پولکادات همیشه یک بلاکچین شاردینگشده و کاملاً ناهمگن بوده است. اکنون، در کنار شاردینگ و ناهمگنی، به بلاکچینی تبدیل خواهد شد که مرزهای شاردینگ آن به صورت سیال تعیین میشود، چیزی که @gavofyork در آن را سیستم نیمههماهنگ نامید. — Kian Paimani (@kianenigma) May 15, 2024 ویژگیهایی که این امر را ممکن میسازند عبارتند از: اجرای بیحالت (state-less) و موازی درونهستهای (parallel in-core execution) که در آن سرویسهای موجود در یک هسته خاص در یک بلوک مشخص تنها میتوانند به صورت همگام تعامل داشته باشند، و دسترسی به اجرای آنزنجیره (on-chain execution) که به یک سرویس اجازه میدهد به نتایج تمام سرویسهای موجود در کل هسته دسترسی پیدا کند. JAM زمانبندی خاصی را برای سرویسها تحمیل نمیکند. سرویسهایی که اغلب با هم ارتباط برقرار میکنند میتوانند مشوقهای اقتصادی به sequencingها ارائه دهند تا بستههای کاری (work packages) حاوی آیتمهای کاری سرویسهای پرکاربرد ایجاد کنند. این سرویسها میتوانند در حالی که در همان هسته حضور دارند، گویی در محیطی همگام هستند با هم ارتباط برقرار کنند. سرویسهای JAM به لایه DA دسترسی دارند و میتوانند از آن به عنوان لایه دادهای موقت اما بسیار ارزان استفاده کنند. به محض ارسال داده به DA، بلافاصله به تمام هستهها پخش شده و در همان هسته بهصورت آنی در دسترس قرار میگیرد. در نتیجه، سرویسهای JAM میتوانند در همان هسته بلوکهای متوالی [7] با زمانبندی خود، دسترسی بالایی به دادهها داشته باشند. باید به یاد داشته باشید که موارد ذکرشده قابلیتهایی هستند که در JAM ممکن است، اما در لایه پروتکل اجباری نشدهاند. برخی رابطها ممکن است از نظر تئوری ناهمگام باشند، اما در عمل از طریق انتزاعهای پیچیده و مشوقها ممکن است به صورت همگام عمل کنند. نمونهای که این موضوع را نشان میدهد، CorePlay است که در بخش بعدی توضیح داده خواهد شد.

۶. ۳. CorePlay

در این بخش، ایده آزمایشی JAM به نام CorePlay توضیح داده میشود. CorePlay مدل جدیدی برای برنامهنویسی قراردادهای هوشمند است که در زمان نگارش این متن به وضوح تعریف نشده است [۸] و هنوز در مرحله ایده است. برای درک CorePlay، ابتدا باید به ماشین مجازی JAM، یعنی PVM نگاهی بیندازیم.

۶. ۳. ۱. PVM

PVM عنصری مهم در JAM و CorePlay است. توضیحات فنی و دقیق PVM در کاغذ خاکستری که توسط متخصصان این حوزه نوشته شده به خوبی بیان شده است، در اینجا فقط چند ویژگی PVM را توضیح میدهیم:

اندازهگیری کارآمد مصرف منابع
قابلیت توقف و از سرگیری اجرا بهویژه دومی قابلیتی مهم برای CorePlay است. CorePlay نمونهای است که با استفاده از primitiveهای سیال JAM، محیطی مقیاسپذیر برای قراردادهای هوشمند با رابط برنامهنویسی ایجاد کرده است. CorePlay پیشنهادی برای استقرار مستقیم قراردادهای هوشمند محور-کنشگر (actor-centric) در هسته JAM فراهم میکند تا رابط برنامهنویسی همگام ممکن شود. کدنویسی معمول با fn main() انجام میشود و برای ارتباط از let _result = other_coreplay_actor(data).await? استفاده میشود. اگر other_coreplay_actor در همان هسته بلوک JAM باشد، این فراخوانی همگام است؛ اما اگر در هسته دیگری باشد، کنشگر متوقف شده و در بلوک بعدی JAM از سر گرفته میشود. این کار به دلیل ماهیت سرویسهای JAM، زمانبندی انعطافپذیر و ویژگیهای PVM ممکن است.

۶. ۴. سرویس CoreChain

در نهایت، با مرور دوباره دلیل اینکه چرا JAM کاملاً با پولکادات سازگار است، این متن را به پایان میبریم. محصول اصلی پولکادات، یعنی زنجیرههای موازی (parachain) به سبک Coretime چابک، در JAM نیز حفظ خواهد شد. اولین سرویسهایی که در JAM مستقر میشوند CoreChain یا همان parachainها خواهند بود. این سرویسای است که به زنجیرههای موازی به سبک پولکادات ۲.۰ اجازه میدهد در JAM اجرا شوند. سرویسهای بیشتری میتوانند در JAM مستقر شوند و سرویسهای CoreChain موجود نیز میتوانند با آنها ارتباط برقرار کنند، اما قابلیتهایی که پولکادات قبلاً ارائه میداد همچنان مهم تلقی میشود و فرصتهای جدیدی برای تیمهای زنجیرههای موازی موجود باز خواهد شد.

پیوست: شاردینگ داده

اگرچه بیشتر این متن مقیاسپذیری را از منظر اجرای شاردینگشده بررسی کرد، اما میتوان آن را از منظر داده نیز بررسی کرد. جالب اینکه با وضعیتی مشابه آنچه در نیمههماهنگی ذکر شد روبرو میشویم. سیستم کاملاً هماهنگ از نظر اصول بهتر است اما مقیاسپذیری دشواری دارد. سیستم کاملاً ناهماهنگ مقیاسپذیر است اما ایدهآل نیست. JAM که ادعای نیمههماهنگی دارد، امکانات جدیدی را ارائه میدهد.

سیستم کاملاً هماهنگ: در پلتفرمهای کاملاً همگام قرارداد هوشمند مانند سولانا، یا پلتفرمهای شجاعی که فقط در اتریوم L1 مستقر میشود، دیده میشود. تمام دادههای برنامه در زنجیره ذخیره شده و به راحتی برای تمام برنامههای دیگر قابل دسترسی است. از نظر برنامهپذیری ویژگی کاملی است اما مقیاسپذیری ندارد.
سیستم ناهماهنگ: دادههای برنامه در شاردهای متفاوت و خارج از L1 ذخیره میشوند. مقیاسپذیری بسیار بالایی دارد اما از نظر ترکیبپذیری (composability) خوب نیست. مدلهای پولکادات و اتریوم رولاپ در این دسته قرار میگیرند. JAM هر دو مورد بالا را فراهم میکند و به برنامهنویسان اجازه میدهد تا دادههای دلخواه را در لایه DA منتشر کنند که میتوان آن را منطقهای میانی بین دادههای آنزنجیره و خارج از زنجیره در نظر گرفت. از این طریق، اکثر دادههای برنامه میتوانند از لایه DA استفاده کنند و فقط اطلاعات کاملاً حیاتی در وضعیت JAM قرار گیرند که امکان ساخت نوعی کاملاً جدید از برنامهها را فراهم میکند.

پیوست: نقشه مقیاسپذیری (Scalability Space Map)

در این بخش، دیدگاههای مربوط به مقیاسپذیری بلاکچین دوباره توضیح داده میشود. این نسخهای مختصرتر از مطالبی است که در کاغذ خاکستری نیز توضیح داده شده است. مقیاسپذیری در بلاکچین اغلب از رویکردهای استفادهشده در سیستمهای توزیعشده سنتی، یعنی مقیاسافزایی عمودی (Scale Up) و مقیاسافزایی افقی (Scale Out) پیروی میکند. پلتفرمهایی مانند سولانا در دسته مقیاسافزایی عمودی قرار میگیرند. این روش با بهینهسازی کد و سختافزار برای رسیدن به بیشترین توان عملیاتی است. اتریوم و پولکادات در دسته مقیاسافزایی افقی هستند. یعنی حجم کاری که همه باید انجام دهند را کاهش میدهند. در سیستمهای توزیعشده سنتی این کار با افزودن ماشینهای تکراری بیشتر انجام میشود. در بلاکچین، "ماشین محاسباتی" همان مجموعه کامل اعتباسنجها (validators) است. با تقسیم اینها و تقسیم کار (روش ELVES) یا کاهش مسئولیت آنها (روش Optimistic Rollup)، میتوان بار کاری کل مجموعه اعتباسنجها را کاهش و در نتیجه سیستم را به صورت افقی مقیاس داد. 💡 مقیاسافزایی افقی در بلاکچین به معنای "کاهش تعداد ماشینهایی است که باید همه چیز را پردازش کنند". خلاصه به شرح زیر است:

Scale Up: روش بلاکچینهای مونولیتیک که بر اساس سختافزار قدرتمند بهینهسازی میشوند.
Scale Out:
Optimistic Rollup
رولاپهای مبتنی بر SNARK
ELIVES: رولاپ تمسخرآمیز پولکادات

پیوست: همان سختافزار، بهروزرسانی کرنل

در این بخش، بر اساس ارائه راب هابرمن (Rob Habermeier) در Sub0 2023: Polkadot: Kernel/Userland | Sub0 2023 - YouTube، توضیح داده میشود که چگونه JAM به عنوان یک بهروزرسانی کرنل روی همان سختافزار میتواند به عنوان یک بهروزرسانی برای پولکادات دیده شود. در یک کامپیوتر معمولی میتوان پشته سیستم کامل را به سه بخش زیر تقسیم کرد:

سختافزار
کرنل
فضای کاربری (User space)

همانطور که قبلاً توضیح داده شد، در پولکادات هستهها (cores) نقش سختافزار را بازی میکنند که نهادههای اصلی محاسبه و در دسترس بودن داده را فراهم میکنند. کرنل پولکادات عملاً [۹] از دو جزء زیر تشکیل شده است:

پروتکل پاراچین: روشی خشک و با نظر مشخص برای استفاده از هسته. مجموعهای از عملکردهای سطح پایین مانند توکن DOT، قابلیت انتقال، استیکینگ و حاکمیت. این دو جزء در حال حاضر در زنجیره رله پولکادات وجود دارند. فضای کاربری (User space): به برنامهها اشاره دارد که شامل پاراچینها، توکنهای بومی آنها و همه چیزهایی است که روی آنها ساخته شده است. این را میتوان به صورت زیر تصویر کرد: پولکادات همیشه میخواسته است که عملکردهای هسته را به کاربران درجه یک، یعنی پاراچینها منتقل کند. هدف "RFC رله مینیمال" (Minimal Relay RFC) نیز همین است. این به این معنی است که فضای کرنل تا حدی کاهش مییابد زیرا زنجیره رله پولکادات فقط بر ارائه پروتکل به پاراچینها تمرکز میکند. هنگامی که این معماری پیادهسازی شود، به راحتی میتوان تصور کرد که مهاجرت به JAM چگونه خواهد بود. JAM فضای کرنل پولکادات را به شدت کاهش میدهد و استفاده گستردهتری از آن امکانپذیر میسازد. همچنین پروتکل پاراچین به فضای کاربری منتقل میشود که این یکی از معدون روشها برای نوشتن برنامهها روی همان هسته (سختافزار) و JAM (کرنل) است. 💡 این توضیحات دوباره تأکید میکند که JAM جایگزین زنجیره رله پولکادات است، نه جایگزین پاراچینها. به عبارت دیگر، مهاجرت JAM میتواند به عنوان یک بهروزرسانی کرنل دیده شود. سختافزار اصلی حفظ میشود و بخشهای زیادی از کرنل قبلی برای سادهسازی به فضای کاربری منتقل میشوند.

منابع

Polkadot 2.0: CorePlay, CoreChains, Corejam, Safrole, PolkaVM - Polkadot by Gavin @PBA4 - YouTube
Gavin Wood: The Gray Paper Interview - JAM & the Future of Polkadot - Behind the Code: Web3 Thinkers - YouTube
Parallel Chain. ↩︎
بلاکچین یا تابع تغییر وضعیت (state transition function). ↩︎
در پولکادات ۱.۰، اثبات وضعیت L2 را PoV (Proof of Validity) و ترکیب اثبات وضعیت و بلوک پاراچین را PVF (Parachain Validation Function) مینامیدند. ↩︎
در کاغذ خاکستری از لایه DA به عنوان "دادهکهر توزیعشده" (Distributed Data Lake, DDL) یاد شده است. در این متن برای سادگی از DA یا لایه DA استفاده شده است. ↩︎
این واقعیت که JAM فقط زنجیره رله پولکادات را جایگزین میکند مهم است. تمام برنامههایی که روی پولکادات از جمله پاراچینها کار میکنند، به لطف CoreChain حفظ میشوند. ↩︎
سومین مورد on_message است که زمانی فراخوانی میشود که پیامی از سرویس دیگری میآید. ↩︎
برای جزئیات بیشتر در مورد زمانبندی سرویس، بخش "Authorization" کاغذ خاکستری را ببینید. ↩︎
بهترین منبع برای CorePlay این پیشنویس RFC است. ↩︎
کلمه "عملاً" مهم است. در ویدیوی ذکرشده نیز، راب پروتکل پاراچین را برنامه فضای کاربری پولکادات نامید. اما این یک فرض تئوریک است؛ پروتکل پاراچین در هسته پروتکل پولکادات، یعنی خود کرنل ادغام شده است. ↩︎