161 / 736CASHU

Cashu

نقد رقمي يعتمد على جهة إصدار محددة

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

Cashu بروتوكول مفتوح لـe-cash، أي رموز رقمية تصدرها جهة تسمى mint. تمثل غالبًا مبالغ بالبيتكوين؛ ويمكن الإيداع أو السحب مثلًا عبر Lightning Network. يتحكم الحامل بالرموز، لا بمفاتيح بيتكوين الجهة المصدرة، ويظل محتاجًا إلى تعاونها.

تخيّل أن آنا ترسل رمز Cashu إلى بيتر في رسالة خاصة. لا تنشر بذلك معاملة Bitcoin على البلوكشين، بل تسلّمه بيانات يستطيع استبدالها لدى جهة الإصدار المعنية. يمكن أن يحتوي الرمز على إثبات واحد أو أكثر (Proof). وهي سجلات بيانات يتضمن كل منها، ضمن معلومات أخرى، مبلغًا وقيمة سرية وتوقيع جهة الإصدار. Cashu بروتوكول مشترك، وليس خدمة واحدة ذات احتياطي مشترك. تهمّ هوية المصدر، ووحدة العملة، ومجموعة مفاتيح التوقيع. المبلغ بوحدة sats يعني أجزاء صغيرة من البيتكوين؛ والرقم نفسه بوحدة أخرى يعني شيئًا مختلفًا. رموز جهة لا تُقبل تلقائيًا لدى جهة أخرى. وللمهتم بالتنسيق، يستخدم V4 ترميز CBOR الثنائي الموفّر للمساحة ويحمل إثباتات جهة إصدار واحدة فقط. [1] [2] [9]

يمكن أن تحتفظ آنا بنسخة من رمز عادي بلا شروط إنفاق إضافية. لذلك يحتاج بيتر إلى swap: تقدم محفظته الإثباتات القديمة إلى mint وتحصل على أخرى جديدة ذات أسرار لا تعرفها آنا. وتبطل الجهة المدخلات القديمة. هذا التبادل الناجح هو ما يمنع آنا من إنفاق النسخة نفسها مجددًا. فحص الحالة وحده لا يكفي. تعني UNSPENT عدم وجود سجل معالجة أو إنفاق، لا حجز الرمز لبيتر. وتعني PENDING أن المعالجة جارية، وSPENT أن الإثبات استُخدم. فلا تنشر الرمز كما تنشر إيصال دفع: من يحصل على نسخة قابلة للاستخدام قد يستبدلها قبلك. [3] [5]

يساعد Blind Signature، التوقيع الأعمى، على فصل إصدار الرمز عن استخدامه لاحقًا. تنشئ المحفظة سرًا، وتخفي تمثيله الرياضي، وتطلب من mint توقيعه، ثم تزيل التعمية. ينبغي ألا تتمكن الجهة من تحديد طلب الإصدار القديم من الرمز المقدّم وحده. لكن ذلك لا يخفي كل شيء: للفئات الاسمية مفاتيح مختلفة، ولذلك تعرف الجهة فئات القيم التي تصدرها. تسمى الطريقة BDHKE وتستخدم منحنى secp256k1. لا تحتاج إلى حساب نقاط المنحنى لفهم الدفع؛ المهم معرفة أي صلة تحميها هذه الرياضيات. [1]

يضيف الامتداد الاختياري NUT-12 إثبات DLEQ، وهو برهان رياضي على أن مفتاح التوقيع الخاص هو نفسه المقابل للمفتاح العام لجهة الإصدار. يستطيع بيتر، مع البيانات المرفقة اللازمة، التحقق من التوقيع دون الاتصال بالجهة. لكن ذلك لا يبيّن إن كانت نسخة أخرى أُنفقت، أو كانت الخدمة تستجيب، أو كان احتياطي البيتكوين كافيًا. إذا أُرفق DLEQ، تلزم المواصفة المحفظة بالتحقق منه. ومع ذلك لا يحل فحص التوقيع محل swap مكتمل. يبقى Counterparty risk، أي خطر إخفاق المشغّل في الوفاء بالتزامه. [7]

قد يريد بيتر دفع طلب عبر Lightning Network بدل الحصول على رموز جديدة. تسمى هذه العملية melt. تطلب المحفظة أولًا عرضًا يحدد مقدار الرموز ووحدتها، ومدة صلاحية العرض، وأي احتياطي للرسوم. وقد تضاف رسوم المدخلات. ثم تقدم الإثباتات وتنفذ الجهة الدفع الخارجي. يعني HTTP 200 نجاح معالجة طلب الويب، وليس بالضرورة نجاح الدفع. فما زالت PENDING تعني «قيد المعالجة»، بينما تبلغ PAID عن النجاح. يجب أن تتابع المحفظة النتيجة النهائية وأي تأكيد خاص بطريقة الدفع. [4]

يمكن لجهة الإصدار تبديل مجموعة مفاتيح التوقيع. تعني active=false أن المجموعة القديمة لا تصدر رموزًا جديدة؛ ولا يمنع ذلك وحده قبول إثباتاتها القديمة كمدخلات. أما final_expiry الاختياري فهو مختلف: بعد هذا الموعد النهائي لا تعود المواصفة تلزم الجهة بالوفاء بوعود الصرف. لا تخلط بين الحالتين. كذلك فإن input_fee_ppk رسم لكل مدخل، وليس مجرد نسبة مئوية من المبلغ المرسل. تُجمع معدلات كل الإثباتات المستخدمة، ثم يُقسم المجموع على 1000، وبعد ذلك فقط تُقرّب الرسوم إلى الأعلى إلى وحدات صحيحة. مثلًا، في مجموعة مفاتيح بوحدة sat، تعطي 3 مدخلات بمعدل 100 ppk لكل منها مجموعًا قدره 300؛ وبعد القسمة والتقريب تكون الرسوم 1 sat. لذا قد تختلف كلفة دفعتين متساويتين إذا اختلف عدد الإثباتات أو مجموعات المفاتيح. [2]

لا يمحو التوقيع الأعمى وقت الدفع، أو المبالغ، أو بيانات الاتصال بالشبكة. وحتى طريقة طلب الفئات الجديدة قد تعطي الجهة قرائن. توصي NUT-03 بترتيب القيم المطلوبة تصاعديًا حتى لا يكشف ترتيبها دون داعٍ تقسيمها إلى دفع وباقٍ. كما قد تسهّل استعلامات المرسل المتكررة عن حالة الرموز المسلّمة ربطه بالمستلم. يقدم Cashu أدوات لتداول المال بخصوصية أكبر؛ ولا يعني أن كل تطبيق وفي كل حالة يخفي تلقائيًا جميع العلاقات. [3] [5]

يجب أن تتوافق الاستعادة مع المحفظة وجهة الإصدار المستخدمتين. تصف NUT-13 إعادة اشتقاق أسرار الرموز وعوامل التعمية من seed، السر الابتدائي، مع مجموعة المفاتيح والعدّاد. تستخدم نسخة المجموعة 01 طريقة HMAC-SHA256، والنسخة الأقدم 00 طريقة BIP32. وتُسترجع التوقيعات التي لا يستطيع seed إنشاءها من الجهة عبر NUT-09، ثم يُفحص ما أُنفق بالفعل. لذلك لا يكفي القول «لدي Seed Phrase وسأستعيد كل شيء في أي محفظة». قبل الاعتماد على محفظة، تحقّق من النسخ والاستعادة وجرّب سحبًا صغيرًا. لا تجبر النسخة الاحتياطية جهة اختفت على الرد، ولا تملأ احتياطيها. [8] [6]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Fedimint, Chaumian eCash, Blind Signature, Lightning Network, Counterparty risk, Satoshi. تشير إلى هذا المدخل أيضًا Chaumian eCash, Blind Signature, Fedimint, Fiduciary Media.

DOC · 001Cashu — NUT-00: Protocol and tokensمواصفة DOC · 002Cashu — NUT-02: Keysets and feesمواصفة DOC · 003Cashu — NUT-03: Swap tokensمواصفة DOC · 004Cashu — NUT-05: Melting tokensمواصفة DOC · 005Cashu — NUT-07: Token state checkمواصفة DOC · 006Cashu — NUT-09: Restore signaturesمواصفة DOC · 007Cashu — NUT-12: Offline signature validationمواصفة DOC · 008Cashu — NUT-13: Deterministic secretsمواصفة DOC · 009Cashu — Project introductionمصدر أولي
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية