ساده سازی آدرس های بیت کوین DNS – مجله بیت کوین
این یک سرمقاله نظری توسط Mark Jeftovic، یکی از بنیانگذاران و مدیر عامل شرکت easyDNS Technologies Inc. و نویسنده “Managing Mission Critical Domains and DNS” است. از لحظه ای که بیت کوین را در سال 2013 کشف کردم، می دانستم که در نهایت باید راهی برای ارجاع به آدرس های کیف پول با استفاده از
این یک سرمقاله نظری توسط Mark Jeftovic، یکی از بنیانگذاران و مدیر عامل شرکت easyDNS Technologies Inc. و نویسنده “Managing Mission Critical Domains and DNS” است.
از لحظه ای که بیت کوین را در سال 2013 کشف کردم، می دانستم که در نهایت باید راهی برای ارجاع به آدرس های کیف پول با استفاده از برچسب های قابل خواندن توسط انسان وجود داشته باشد.
مشکل بزرگ آدرس‌های طولانی بیت‌کوین این است که به یاد ماندنی نیستند، و با وجود ویژگی‌های مستعار یا ناشناس بیت‌کوین، اغلب اوقات می‌خواهید بتوانید به راحتی ادعا یا تأیید کنید که آدرس کیف پول متعلق به یک نهاد خاص است – فکر کنید کمک های مالی به یک موسسه خیریه یا یک صندوق جمعی. این روی هر بلاک چین تاثیر می گذارد.
به عنوان یک فرد DNS (سیستم نام دامنه)، من قبلاً این فیلم را دیده بودم: DNS برای حل همان مشکل با آدرس دهی IPv4 اختراع شد. با گذشت زمان DNS تکامل یافت تا کارهای بیشتری انجام دهد – نه تنها DNS قابلیت حل و فصل آدرس های IPv6 را اضافه کرد، بلکه به طور فزاینده ای برای انتقال ابرداده در مورد یک فضای نام استفاده می شود. به رکوردهای SRV، NAPTR، لیست‌های بلاک RBL، مناطق سیاست پاسخ (RPZ) و رکورد TXT در همه جا (که برای SPF، DMARC، DKIM و هر چیز دیگری که به طور طبیعی با پروتکل مطابقت ندارد استفاده می‌شود) فکر کنید.
در کنار بیت کوین می آید و ما همین مشکل را داریم.
مشکل خاص بیت کوین و لایتنینگ
به نظر می‌رسد که بسیاری از فعالیت‌های تراکنش پرداخت با پروتکل‌هایی مانند Lightning و اخیراً ظهور Lightning Address به لایه 2 منتقل می‌شود.
آدرس‌های لایتنینگ به پروتکل LNURL-pay متکی هستند و تقریباً شبیه یک آدرس ایمیل هستند:
نامگذاری آدرس ایمیل بهترین راه برای انتقال اطلاعات هویتی است. به راحتی سازمان ها را مشخص می کند و بیشتر به واحدها یا افراد درون آن تقسیم می شود. همه قبلاً به این قالب عادت کرده‌اند و همانطور که خواهیم دید، پتانسیل انتقال اطلاعات بسیار بیشتری نسبت به صندوق‌های پستی مقصد را دارند.
سال‌ها پیش‌بینی می‌کردم که این قالب به استاندارد واقعی برای نقاط پایانی هویت با پروتکل شروع جلسه (SIP) و XMPP تبدیل شود.
SIP و XMPP آنطور که من انتظار داشتم (حداقل هنوز نه) دنیا را تصاحب نکردند و برای مدتی، شناسه ها به سمت پلتفرم های متمرکز مانند دسته های توییتر و شناسه های کاربری Github جذب شدند. من همیشه این سوال را پیدا می کردم، به خصوص در بین بیت کوینی ها.
با آدرس‌های لایتنینگ، مسیری را به سمت شناسه‌های غیرمتمرکز می‌بینیم، زیرا آدرس‌های ایمیل خود غیرمتمرکز هستند، در محدوده خود سیستم DNS (در ادامه در مورد آن بیشتر توضیح می‌دهیم).
تنها یک مشکل وجود دارد: مشخصات LNURL همانطور که تعریف شده است سطحی از انتزاع را از دست داده است. بدون آن، استفاده از آدرس های روشنایی بسیار محدود می شود.
با توجه به آدرس لایتنینگ:
این بدان معناست که تحت مشخصات فعلی، توصیفگر پرداخت در این آدرس قرار خواهد گرفت:
https://example.com/.well-known/lnurlp/satoshi/
اما اگر ساتوشی به وب سرور example.com دسترسی نداشته باشد چه؟ اگر به قیاس آدرس ایمیل پایبند باشیم: فقط به این دلیل که این آدرس را به عنوان آدرس خود دارید به این معنی نیست که سرور با نام میزبان منطبق جایی است که ایمیل تحویل داده می شود.
در واقع این احتمالاً بیشتر از آنچه هست اینطور نیست. به همین دلیل نوع رکورد MX در DNS وجود دارد که یک سطح غیر مستقیم برای کنترل مقصد ایمیل اضافه می کند. آنها ممکن است تحویل ایمیل را به نام های میزبانی که تحت نام دامنه کاملاً متفاوتی کار می کنند هدایت کنند (به افرادی فکر کنید که از یک ارائه دهنده ایمیل خارجی استفاده می کنند، اما با دامنه سفارشی خودشان).
همان چیزی که باید در مورد آدرس های لایتنینگ نیز به دلایل مشابه اتفاق بیفتد. نام میزبان در سمت راست «@» ممکن است اصلاً وب سرور نداشته باشد، یا کاربر به ناحق به استفاده از آدرس لایتنینگ محدود شده است که در آن مؤلفه نام میزبان فقط می‌تواند مربوط به وب سروری باشد که فایل JSON در آن میزبانی می‌شود. این می تواند هنگام انتشار یک آدرس لایتنینگ که کاربر می خواهد آن را تغییر دهد، مشکل ساز باشد.
به عنوان یک مرد DNS، راه حل واضح به نظر می رسید، اما من مقصر بودم که بیش از حد به آن فکر کردم:
در سال 2017 از طرف گروه کاری سرویس نام اتریوم که در آن زمان بود به جلسه ای در لندن دعوت شدم تا مشخصات رجیستری ENS را بررسی کنم.
من آن جلسه را با این فکر ترک کردم که باید یک رکورد منبع DNS جدید وجود داشته باشد، یک نوع رکورد جدید که بتواند منابع بلاک چین را از درون DNS قدیمی ارجاع دهد.
در ذهن من چیزی شبیه یک رکورد SRV یا NAPTR به نظر می رسد که دارای فیلدهای مختلف برای پروتکل ها، پورت ها و وزن است (این واقعیت که مرورگرهای وب امروز هنوز به رکوردهای SRV برای آدرس های وب نگاه نمی کنند یکی از فرصت های بزرگ از دست رفته است. عصر اینترنت).
خلاصه کار من برای آن «BCPTR» برای «اشاره‌گر بلاک‌چین» بود و دارای مشخصات پیچیده و پیچیده‌ای بود که نشان می‌داد یک رکورد دقیقاً به کدام بلاک چین اشاره می‌کند و چه نوع منبعی است.
سپس در موضوع Lightning GitHub، جایی که LNURL RFC مورد بحث قرار گرفت، کسی پیشنهاد داد که به سادگی یک آدرس با زیر دامنه “_lud16” اضافه شود.
استفاده از زیرخط برای متمایز ساختن ویژگی‌های نامگذاری خاص از نام‌های میزبان واقعی، مدتی است که وجود داشته است. در مشخصات اصلی SRV RR RFC2872 مورد استفاده قرار گرفت و بعداً به عنوان “محدوده زیرین” در RFC 8552 توصیف شد.
این پیشنهاد بلافاصله در مغزم منفجر شد و متوجه شدم که سالهاست بیش از حد به این موضوع فکر کرده ام.
برچسب‌های scoped در DNS، مانند _tcp یا _udp، به حروف بزرگ و کوچک حساس نیستند و ما آنها را در رکوردهای SRV و NAPTR برای استفاده در برنامه‌های SIP، VOIP و ENUM، متعادل‌سازی بار مشاهده می‌کنیم.
تقریباً هر برچسب DNS معتبر، مانند _lud16 یا _btc، مکانیزمی را برای ما فراهم می کند تا پاسخی را به یک پرس و جو مطابق با محدوده، در زیر گره والد در درخت DNS محدود کنیم.
معنی:
$ORIGIN example.com.
_ie.test در TXT “این یک تست است”_eg.test IN TXT “این یک تست جداگانه است”
پرس و جوی DNS برای نوع TXT در “test.example.com” پاسخی (NXDOMAIN) بر نمی گرداند.
یک پرس و جو DNS برای نوع TXT در “_ie.test.example.com” خواهد بود فقط نتیجه را برای اولین رکورد برگردانید.
یک پرس و جو DNS برای نوع TXT در “test._ie.example.com” انجام خواهد شد فقط رکورد دوم را برگردانید
به عبارت دیگر، چندین رکورد TXT برای آن داریم test.example.com برگ، با این حال، ما فقط موردی را که با برچسب scoped درخواست شده است، برمی گردانیم، برچسبی که با زیرخط شروع می شود.
به نظر می رسد که این برای اهداف ما بسیار قدرتمند است. همچنین ساده ترین و بهینه ترین راه حل در مورد استفاده ما است زیرا:
- همه می توانند از آن استفاده کنند.
- این قالبی است که مردم به راحتی تشخیص می دهند.
- می توان آن را بر روی هر آدرس ایمیل موجود از طریق DNS نصب کرد.
- این امکان را فراهم می کند که یک رکورد json در جایی غیر از سرور وجود داشته باشد (مانند نحوه عملکرد یک رکورد MX).
- می تواند هر نوع باری را ارائه دهد.
- می تواند در تمام بلاک چین ها کار کند.
چگونه می توان از Underscore Scoping در بلاک چین استفاده کرد؟
با استفاده از فرمت آدرس ایمیل استفاده شده در آدرس های لایتنینگ: می توانیم از قرارداد از طریق DNS برای تعیین انواع نقاط پایانی برای یک هویت استفاده کنیم:
$ORIGIN bombthrower.com.
_lud16.markjr در TXT “https://my.ln-node/.well-known/lnurlp/markjr”
_btc.markjr در TXT “bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl”
_ens.markjr در TXT “0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb”
ما می‌توانیم از اینجا به آنجا برسیم بدون اینکه چیزی را که قبلاً در جای خود است خراب کنیم:
- برنامه هایی که قبلاً از آدرس LNURL استفاده می کنند همیشه می توانند از آن استفاده کنند
- برنامه ها می توانند جستجوی DNS را اضافه کنند
اما DNS متمرکز است!
درست است که DNS دارای ساختار درختی معکوس است که به ریشه “.” ختم می شود. اما حتی آن ریشه نیز نسبتاً غیرمتمرکز است و شامل هزاران سرور است که توسط حداقل 13 اپراتور متفاوت اداره می شوند. DNS قدیمی ممکن است از نظر منطقی متمرکز باشد، اما در واقعیت بیشتر شبیه به یک فدراسیون غیرمتمرکز عمل می کند.
حتی این در حال تغییر و تحول است. من فکر می‌کنم جایی که در نهایت به پایان می‌رسیم جایی است که فضاهای نام هم ریشه درخت معکوس موجود و هم زنجیره‌های بلوکی کاملاً غیرمتمرکز را در بر می‌گیرند.
برخی از این موارد در حال حاضر در اینجا وجود دارد: می توانید از چیزی مانند Stacks و دامنه های .btc استفاده کنید که به بیت کوین پین می شوند و احتمالاً فضاهای نام دیگری مستقیماً در بالای بیت کوین ساخته می شوند.
همه فضاهای نام غیرمتمرکز دارای حل‌کننده‌های DNS قدیمی نیستند، اما این نیز تغییر خواهد کرد. همچنین روی یک پیاده‌سازی DNSresolvers جدید کار انجام می‌شود که دامنه‌های Stacks، .btc، و HNS را توسط Handshake و دامنه‌های سطح بالای Unstoppable حل می‌کند. می توانید آن را از طریق جستجو در alpha.dnsresolvers.com آزمایش کنید:
% dig + short easydns.btc @alpha.dnsresolvers.com
3.14.49.122
(این سرور اثبات مفهوم است و در آینده از بین خواهد رفت، لطفا آن را اضافه نکنید به resolv.conf شما.)
همه اینها، و مشکل دسته توئیتر جعلی را نیز حل می کند!
هنگامی که استفاده از محدوده زیر خط را به یک قرارداد تبدیل می کنیم، متوجه می شویم که می توانیم انواع مشکلات را با استفاده از روش های موجود حل کنیم.
بیایید به مشکل دسته جعلی توییتر که فضای بیت کوین را آزار می دهد نگاه کنیم.
ساختار داده یک کاربر توییتر به شکل زیر است:
با زیرخط محدوده، می‌توانیم دسته واقعی توییتر را از نام میزبان در عنصر url با استفاده از قرارداد زیر مشخص کنیم:
$ORIGIN bombthrower.com.
stuntpope._twitter IN TXT “StuntPope”
*._twitter در TXT “جعلی”
این به خودی خود هیچ کاری نمی کند. هیچ کس قرار نیست یک پنجره ترمینال را باز کند و تایپ کند:
“dig -t TXT + stuntpope کوتاه._twitter.bombthrower.com”
… برای اینکه بفهمید آیا شخصی که به شما پیام می دهد، “امروز معاملات شما چگونه پیش می رود؟” واقعا من هستم یا یکی از لژیون ها متقلبان StuntPope در توییتر. (البته شوخی می‌کنم، هیچ کس عاقل من را جعل نمی‌کند. اما برای بسیاری از روشنفکران فینت‌ویت، این یک مشکل واقعی است.)
اما آنچه می تواند اتفاق بیفتد، این است که توسعه دهندگان می توانند قلاب های سریع و کثیفی را در برنامه های خود ایجاد کنند تا این جستجوها را انجام دهند.
هنگامی که یک نمایه جعلی توییتر جعل هویت شخصی را نشان می دهد، آنها معمولاً تمام داده ها را کلمه به کلمه کپی می کنند، از جمله نام میزبان در قسمت URL نمایه توییتر. اگر کاربر واقعی سوابق ذکر شده در بالا را داشته باشد، پس قرارداد جستجوی آن است جعلی دسته توییتر در واقعی URL رکورد واقعی _twitter TXT را برای نمایه واقعی از دست می دهد و به رکورد wildcard ضربه می زند و باعث عدم تطابق می شود.
ما یک افزونه اثبات مفهوم کروم را از طریق easyDNS Github منتشر کرده‌ایم که این کار را با سه حالت انجام می‌دهد:
الف) هیچ اطلاعاتی اظهار نشده است.
ب) نمایه با اطلاعات بیان شده مطابقت دارد.
ج) نمایه با اطلاعات اعلام شده مطابقت ندارد (جعلی است).
همه اینها و موارد دیگر را می توان با استفاده از قراردادهای بسیار ساده در یک پروتکل همه جا حاضر که قبلاً مستقر شده است انجام داد.
نتیجه
آدرس های کیف پول نیاز به مکانیزم نامگذاری دارند. موارد استفاده متعددی وجود دارد که در آن نیاز به ارائه ایمن آدرس از یک هویت بر نام مستعار یا ناشناس بودن ارجحیت دارد.
علاوه بر این، برای استفاده از برچسبها یا شناسه‌های قابل خواندن توسط انسان، به یک لایه انتزاعی نیاز داریم که انعطافپذیری و قالبی را فراهم کند که به راحتی قابل تشخیص باشد.
در نهایت، ما می‌توانیم با استفاده از DNS، که زیرساخت فنی اینترنت را زیربنا می‌دهد، به همه اینها دست یابیم، در حال حاضر یک فدراسیون غیرمتمرکز است و در راه است تا بر روی پروتکلهای لایه 1 غیرمتمرکز لنگر بیاندازد. ما می توانیم این کار را بدون افزودن انواع رکوردهای جدید یا افزودن پروتکل به مشخصات موجود انجام دهیم.
این یک پست مهمان توسط مارک جفتویچ است. نظرات بیان شده کاملاً متعلق به خود آنها است و لزوماً نظرات BTC Inc یا را منعکس نمی کند مجله بیت کوین.
 آموزش مجازی مدیریت عالی حرفه ای کسب و کار Post DBA+ مدرک معتبر قابل ترجمه رسمی با مهر دادگستری و وزارت امور خارجه |  آموزش مجازی مدیریت عالی و حرفه ای کسب و کار DBA+ مدرک معتبر قابل ترجمه رسمی با مهر دادگستری و وزارت امور خارجه |  آموزش مجازی مدیریت کسب و کار MBA+ مدرک معتبر قابل ترجمه رسمی با مهر دادگستری و وزارت امور خارجه |
 مدیریت حرفه ای کافی شاپ |  حقوقدان خبره |  سرآشپز حرفه ای |
 آموزش مجازی تعمیرات موبایل |  آموزش مجازی ICDL مهارت های رایانه کار درجه یک و دو |  آموزش مجازی کارشناس معاملات املاک_ مشاور املاک |
- نظرات ارسال شده توسط شما، پس از تایید توسط مدیران سایت منتشر خواهد شد.
- نظراتی که حاوی تهمت یا افترا باشد منتشر نخواهد شد.
- نظراتی که به غیر از زبان فارسی یا غیر مرتبط با خبر باشد منتشر نخواهد شد.
ارسال نظر شما
مجموع نظرات : 0 در انتظار بررسی : 0 انتشار یافته : ۰