الرئيسيةأخبارأخبار بيتكويناستخدام DNS لتنسيق مدفوعات البيتكوين

استخدام DNS لتنسيق مدفوعات البيتكوين

إعلانات
إعلانات
إعلانات
إعلانات



اقترح مات كورالو منذ أكثر من أسبوع بقليل BIP لتنسيق إجراء مدفوعات البيتكوين. لقد شكل إجراء عمليات الدفع بالبيتكوين دائمًا تحديًا من حيث التنسيق، سواء داخل السلسلة أو خارجها مع بروتوكولات مثل Lightning، لأسباب مختلفة. عندما يتعلق الأمر بالأنظمة الرقمية مثل البريد الإلكتروني أو أنظمة الدفع مثل Paypal وCashapp وما إلى ذلك، فإن الأشخاص معتادون جدًا على مفهوم المعرف الثابت الواحد. إذا كنت تريد إرسال بريد إلكتروني إلى جون، فما عليك سوى إرسال بريد إلكتروني إلى “john@”[insert domain]”. إذا كنت تريد إرسال بعض الأموال إلى John على Cashapp، فما عليك سوى إرسال دفعة إلى @John على Cashapp.

هذه هي تجربة المستخدم التي يعرفها الأشخاص، وعندما يتعلق الأمر بسلوك المستخدم الراسخ وتوقعاته بشأن الأشياء، فمن الصعب للغاية دفعهم إلى تغيير جوهري أو حاد في سلوكهم. إذا قدمت لهم أداة تتطلب ذلك، فإن ذلك يمثل درجة كبيرة من الاحتكاك وعلى الأرجح سيؤدي ببساطة إلى تثبيط معظم الناس عن استخدام هذه الأداة.

تواجه المدفوعات عبر السلسلة مشكلة مع هذا التوقع، ليس بسبب عدم القدرة على الحصول على معرف ثابت (عنوان واحد)، ولكن بسبب الآثار المترتبة على الخصوصية لنشر عنوان واحد على السلسلة وجعل كل شخص تتفاعل معه يستخدم ذلك. ليدفع لك. فهو يضع سجل الدفع بالكامل وملكية العملات المعدنية في مرأى الجميع. إذا كنت نادرًا ما تتلقى أموالًا بين الحين والآخر، على سبيل المثال، عندما تحصل على أموال مقابل العمل أو تسوية علامات التبويب مع الأشخاص، فليس عبئًا على الإطلاق أن تفتح محفظتك وتنشئ عنوانًا جديدًا للوصول إليه. ومع ذلك، إذا كنت تتلقى الأموال بشكل متكرر، خاصة في الحالات التي لا تطلب فيها الدفع بشكل مباشر، فإن ذلك يمثل عبئًا خطيرًا.

ولهذا السبب تم إنشاء أدوات مثل BTCPay Server، من أجل تقليل حاجز الدخول للأشخاص لتشغيل البنية التحتية اللازمة لأتمتة تلقي الأموال دون القيام بشيء ساذج مثل نشر عنوان واحد لكل شخص يدفع لك مقابل إعادة الاستخدام. ومع ذلك، فإن هذا يتطلب تشغيل خادم متاح باستمرار عبر الإنترنت. على الرغم من أن المشروع قد خفض بشكل كبير مستوى الفهم المطلوب، إلا أنه لا يزال يمثل عبئًا كبيرًا على المستخدم الذي يريد ببساطة أن يكون قادرًا على تلقي الأموال بشكل سلبي.

وينطبق الشيء نفسه على البرق إلا ما هو أسوأ. الفاتورة صالحة فقط لدفعة واحدة. على عكس العنوان الموجود على السلسلة، والذي يمكن إعادة استخدامه على الرغم من أن هذه ممارسة فظيعة، لا يمكن استخدام فاتورة Lightning. بمجرد دفع الفاتورة أو انتهاء صلاحيتها، سترفض عقدة Lightning المعنية أي محاولة لدفعها. أدت هذه الديناميكية إلى إنشاء مواصفات LNURL، بالإضافة إلى عناوين Lightning المبنية فوقها. LNURL هو بروتوكول للاتصال بخادم HTTP من خلال عنوان IP ثابت يمكن مشاركته مرة واحدة للحصول على فاتورة Lightning فعلية للدفع من الخادم. علاوة على ذلك، فإن Lightning Addresses عبارة عن نظام تسمية أعلى LNURL منظم بشكل مشابه لعناوين البريد الإلكتروني: John@[domain of LNURL server].

كل هذه الحلول لها سلبيات. متطلبات تشغيل برنامج إضافي (خادم HTTP) يظل متصلاً بالإنترنت طوال الوقت بالإضافة إلى محفظة Bitcoin أو عقدة Lightning؛ يؤدي تقديم طلب إلى خادم BTCPay/LNURL إلى تسريب عنوان IP الخاص بالمرسل إلى المستلم؛ الاعتماد على سلطات شهادة TLS.

فقط استخدم DNS

تستخدم أدوات خادم HTTP مثل LNURL عند إقرانها بـ Lightning Address المجالات لحل الاتصال بخادم HTTP. وبالمثل، يتم تكوين جميع خوادم BTCPay باستخدام المجالات بدلاً من استخدام عناوين IP الأولية. إن رؤية مات هي لماذا لا نتوقف عن الاعتماد على HTTP ونستخدم نظام اسم المجال نفسه؟

يسمح لك DNS بربط سجلات TXT باسم مجال معين، مما يؤدي إلى إنشاء سجلات صغيرة يمكن قراءتها بواسطة الإنسان (أو الجهاز) والتي يمكن الاستعلام عنها من خوادم DNS. بالاشتراك مع ملحقات أمان نظام اسم المجال (DNSSEC)، توفر سجلات DNS TXT آلية يمكن استخدامها للاستعلام عن معلومات الدفع دون تحمل عبء تشغيل خادم HTTP، فضلاً عن توفير قدر أكبر من المرونة والانفتاح. يوفر DNSSEC عددًا من الأدوات لتوقيع إدخالات DNS بشكل مشفر، بما في ذلك سجلات TXT، مع مفاتيح DNS المتأصلة في البنية الهرمية لـ DNS. يوفر هذا ضمانًا بأن سجل TXT الذي تستعلم عنه هو السجل الموقع والموزع على خوادم DNS ذات المستوى الأدنى من خادم/مفتاح الجذر المحلي.

يؤدي هذا إلى تحقيق الفائدة الحقيقية لنظام DNS كوسيلة لجلب بيانات الدفع: قل وداعًا لمتطلبات تشغيل خادم HTTP. يمكن لسجل TXT تشفير عنوان Bitcoin على السلسلة (على الرغم من أن BIP يوصي على وجه التحديد بعدم القيام بذلك إذا لم تكن قادرًا على تدوير العناوين الجديدة بانتظام لمنع إعادة استخدام العنوان)، ولكن الأهم من ذلك أنه يمكن أن يحتوي أيضًا على عرض BOLT 12 Lightning.

يمكن جلب هذه السجلات من أي خادم DNS، أو من خادمك المحلي، أو من مزود خدمة الإنترنت، أو حتى من خادم عام مثل Google أو Cloudflare. من هذه النقطة الأساسية، تم حل أحد أوجه القصور في الحلول المعتمدة على HTTP؛ لم تعد تقوم بتسريب عنوان IP الخاص بك إلى الشخص الذي تحاول الدفع له. الآن، في حالة استخدام DNS الخاص بمزود خدمة الإنترنت أو خادم عام مثل Google أو Cloudflare بدون VPN أو Tor، فإنك تكشف لهم عنوان IP الخاص بك؛ من الواضح أن BIP يشجع دعم تحليل DNS عبر VPN أو Tor لهذا السبب على وجه التحديد.

يؤدي الجمع بين هذا الاقتراح مع BOLT 12 إلى إزالة الحاجة إلى تشغيل البرامج المساعدة التي تمثل مصدر قلق أمني حقيقي للغاية للمستخدمين غير المتطورين، وتسمح بملكية النطاق وحده لمنح المستخدمين كل ما يحتاجون إليه ليكون لديهم آلية لتحديد موقع معلومات الدفع باستخدام إنسان بسيط معرف قابل للقراءة. لا يتطلب BOLT 12 أي خادم HTTP، حيث يتعامل مع تسليم الفاتورة الفعلي عبر الاتصالات الموجهة مباشرة من خلال شبكة Lightning Network، ويدعم العروض، وهو معرف ثابت يمكن استخدامه للعثور على طريق البصل إلى عقدة Lightning تلك. تكمن المشكلة في أن العرض يتم ترميزه كسلسلة عشوائية ضخمة مثل الفاتورة نفسها، مما يجعله معرفًا بشريًا فظيعًا يمكن قراءته/استخدامه إلا من خلال استخدام رموز QR أو النسخ واللصق.

من خلال تخزين العرض في سجل DNS TXT، كل ما يحتاجه المستخدم لإجراء الدفع هو المجال الخاص بشخص ما ليكتبه في محفظته حتى يتمكن من جلب سجل TXT، وجلب عرض BOLT 12، ثم إجراء الدفع. لا يحتاجون إلى استضافة أي خادم أو تشغيل أي برنامج بخلاف عقدة Lightning الخاصة بهم، حيث يتعامل نظام DNS مع كل شيء بالنسبة لهم بقدر استضافة BOLT 12. قم بتقديم شخص يمكن للمستخدمين الراغبين في الدفع لهم العثور عليه.

هل هذا نظام غير موثوق به تمامًا؟ لا، هل هو أفضل بكثير من الأنظمة المعتمدة على HTTP؟ قطعاً. المشكلة في مثل هذه المشكلات هي أن هناك توقعات معينة لتجربة المستخدم والسلوك لدى معظم الناس بقدر ما يفترض أن تعمل الأنظمة الرقمية في أذهانهم. وبدون تكرار تجربة المستخدم هذه، ستستخدم مجموعات كبيرة من الأشخاص ببساطة البدائل التي تلبي توقعات تجربة المستخدم هذه. بالنظر إلى هذا الواقع، في محاولة دمج Bitcoin في صندوق توقعات تجربة المستخدم، يجب أن يكون هدف التصميم هو تلبية احتياجات المستخدم مع الحد الأدنى من الثقة المتبادلة، والحد الأدنى من العبء الواقع على المستخدمين، والحد الأدنى من إمكانية فقدان الخصوصية بطرق جديدة. أعتقد أن Matt’s BIP يتحقق من كل هذه المربعات مقارنة بالحلول الحالية.

إعلانات
مقالات ذات صلة
- إعلانات -

الأكثر شهرة

- إعلانات -