اشتراک گذاری

اشتراک گذاری

اشتراک گذاری

اشتراک گذاری

با توجه به ادامه نوآوری در پول و پرداخت ، بسیاری از بانکهای مرکزی در حال بررسی ایجاد ارز دیجیتال بانک مرکزی (CBDC) هستند ، شکل جدیدی از پول بانک مرکزی که مکمل مانده حساب ذخیره بانک مرکزی و ارز فیزیکی 5 است. CBDC ها بسته به اهداف یک بانک مرکزی می توانند به اشکال مختلفی وجود داشته باشند ، از جمله CBDC با هدف کلی که می تواند برای پرداخت خرده فروشی ، تجارت الکترونیکی و شخص به شخص در دسترس عموم باشد. بانک های مرکزی ، محققان و سیاست گذاران اهداف مختلفی از جمله تقویت شمول مالی ، بهبود کارآیی در پرداخت ، ایجاد نوآوری در خدمات مالی ، حفظ ثبات مالی و ارتقاء حریم خصوصی 2 3 9 19 را ارائه داده اند.

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

بانک مرکزی فدرال رزرو بوستون (بوستون فدرال) و ابتکار مؤسسه ارز دیجیتال فناوری ماساچوست (MIT DCI) در تحقیقات اکتشافی موسوم به پروژه همیلتون ، یک پروژه تحقیقاتی چند ساله برای کشف فضای طراحی CBDC و به دست آوردن درک دستی همکاری می کنند. از چالش ها و فرصت های فنی CBDC. در این مقاله تحقیقات فاز 1 پروژه ارائه شده است. هدف اصلی ما طراحی یک پردازنده اصلی معامله بود که با سرعت ، توان و نیازهای تحمل گسل یک سیستم پرداخت خرده فروشی بزرگ را برآورده کند. هدف ثانویه ما ایجاد یک بستر انعطاف پذیر برای همکاری ، جمع آوری داده ها ، مقایسه با معماری های متعدد و سایر تحقیقات آینده بود. با این هدف ، ما تمام نرم افزارها را از تحقیقات خود به طور عمومی تحت مجوز منبع باز MIT منتشر می کنیم.

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

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

1. طراحی و نتایج اصلی

در فاز 1 ، ما طرحی را برای یک سیستم پردازش معاملات ماژولار و گسترده ایجاد کردیم ، آن را در دو معماری مجزا پیاده سازی کردیم و سرعت ، توان و تحمل گسل آنها را ارزیابی کردیم. علاوه بر این ، طراحی ما می تواند از مدل های مختلفی برای واسطه ها و ذخیره سازی داده ها ، از جمله کاربرانی که بودجه خود را باز می کنند پشتیبانی کند و نیازی به ذخیره شخصاً شناسایی داده های کاربر در هسته پردازنده معامله نداشته باشد.

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

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

هر دو معماری از سرعت و نیازهای توان ما برآورده شده و فراتر رفته اند. اولین معماری معاملات را از طریق یک سرور سفارش دهنده پردازش می کند که معاملات کاملاً معتبر را در دسته ها یا بلوک ها سازماندهی می کند و تاریخچه معامله سفارش داده شده را تحقق می بخشد. این معماری بیش از 99 ٪ معاملات را در دو ثانیه به پایان رساند و بیشتر معاملات در کمتر از 0. 7 ثانیه. با این حال ، سرور سفارش منجر به تنگنا شد که منجر به توان اوج تقریباً 170،000 معاملات در ثانیه شد. معماری دوم ما معاملات را به طور موازی بر روی رایانه های مختلف پردازش می کند و برای جلوگیری از هزینه های مضاعف به یک سرور سفارش واحد متکی نیست. این منجر به مقیاس پذیری برتر می شود اما تاریخچه سفارش داده شده را برای همه معاملات تحقق نمی بخشد. این معماری دوم با 99 ٪ معاملات که به طور قابل توجهی در زیر یک ثانیه انجام می شود ، عملکرد 1. 7 میلیون معاملات در ثانیه را نشان داد و اکثر معاملات در کمتر از نیم ثانیه انجام می شود. همچنین به نظر می رسد با افزودن سرورهای بیشتر به صورت خطی مقیاس می شود. به منظور تأمین مقاومت ، هر معماری می تواند از دست دادن دو مکان دیتاسنتر (به عنوان مثال ، به دلیل بلایای طبیعی یا از بین رفتن اتصال به شبکه) تحمل کند ، در حالی که یکپارچه به پردازش معاملات و بدون از دست دادن داده ادامه می دهد.

2. یادگیری

فاز 1 چندین یادگیری کلیدی در طراحی بالقوه یک CBDC ظاهر شده است:

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

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

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

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

گزینه های طراحی CBDC گرانول تر از آنچه معمولاً تصور می شود است. در حال حاضر ، طرح های CBDC به عنوان مدل های مستقیم ، دو لایه یا ترکیبی ، با مدل های دسترسی "توکن" یا "حساب" طبقه بندی می شوند 1 2 7 12 15. ما این دسته بندی های محدود را پیدا کردیم که فاقد پیچیدگی انتخاب در دسترسی ، واسطه گری ، نقش نهادی و حفظ داده ها در طراحی CBDC 10 باشد. به عنوان مثال ، کیف پول ها می توانند بدون توجه به نحوه ذخیره وجوه در پایگاه داده ، از نمای تعادل حساب و یک نمای خاص سکه برای کاربر پشتیبانی کنند.

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

با اجرای یک سیستم قوی ، ما سؤالات جدیدی را برای طراحان CBDC و سیاست گذاران برای پرداختن به آنها ، در مورد تجارت در عملکرد ، قابلیت حسابرسی ، عملکرد و حریم خصوصی شناسایی می کنیم. کار ما سؤالات مهمی را برای پرداختن به چگونگی تأثیر معماری فنی بر استفاده و عملکرد CBDC در پرداخت ها مطرح کرد. به عنوان مثال ، این یک سؤال باز است که از منظر اقتصادی چقدر مهم است که از معاملات اتمی پشتیبانی کند. در پارلمان پایگاه داده ، این به معنای چندین عملیات به قطعات مختلف داده ها به شکلی اعمال می شود که فوری (اتمی) ظاهر می شود ، یا مجموعه به روزرسانی ها به هیچ وجه اتفاق نمی افتد. هیچ برنامه جزئی 4 14 وجود ندارد. در زمینه پردازنده پرداخت ، این بدان معناست که کاربران می توانند با اطمینان پرداختی را صادر کنند که ممکن است چندین صورتحساب (یا وجوه از حساب های مختلف) را به طور کامل منتقل کنند ، و هرگز انتقال جزئی را مشاهده نمی کنند ، حتی اگر تصادفات یا خطاهای سیستم وجود داشته باشد. ما تصمیم به اجرای معاملات اتمی گرفتیم که تأثیر مستقیمی بر عملکرد سیستم 8 دارد.

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

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