Dandelion++

يستهدف Dandelion++ أثرًا شبكيًا محددًا: استنتاج IP الخاص بـ origin node من المكان الذي تبدأ منه transaction الجديدة بالانتشار. لا يشفّر transaction ولا يخفي amounts أو addresses ولا يزيل الآثار الباقية في public blockchain. [1]

للـ relay مرحلتان. في stem لا تُرسل transaction إلى كل peers بل تسلك route ضيقًا pseudorandom؛ وعندما ينتقل node إلى fluff يبدأ diffusion المعتاد. ينشأ بذلك تأخير وغموض بين source الحقيقي وأول موضع للانتشار الواسع. [1]

في كل epoch تقارب 10 دقائق ينشئ Dandelion++ من outbound peers مختارين anonymity graph يقارب 4-regular. يختار node حتى 2 stem relay connections، ويحد التعيين الجديد في epoch التالية من مراقبة route ثابت طويلًا. [1]

تخرج transactions الخاصة بـ node من stem edge نفسها داخل epoch، بينما تُربط transactions المستلمة من incoming edge إلى outbound edge. يُختار دور relay أو diffuser بصورة pseudorandom لكل node وepoch لا لكل transaction، لمعالجة graph-learning وintersection attacks ضد Dandelion الأصلي. [1]

لا يُعد Dandelion++ paper ‏Bitcoin BIP نشطًا. وصف BIP 156 إصدار Dandelion الأقدم وأُغلق بلا implementation؛ واقترح Bitcoin Core issue 20203 ‏Dandelion++ لكنه مغلق الآن ولا يرفق branch أو pull request. لذلك لا يستخدم Bitcoin Core العادي Dandelion++ افتراضيًا. [3]

يمكن للمهاجم تجربة black-hole attack أو احتلال Sybil positions أو تعلم topology أو ربط عدة transactions. يحوّل random fail-safe embargo timer ‏transaction إلى fluff إذا لم ير node انتشارها في الوقت المناسب؛ وهذا يحسن liveness، لكن timing وpartial deployment يظلان مصدرًا للتسريب والتأخير. [4]

يمكن جمع Dandelion++ مع Tor أو I2P، لكن الوظيفة مختلفة. تخفي anonymity network مسار النقل للـ connection، بينما يغيّر Dandelion++ ‏transaction gossip بين Bitcoin peers؛ ولا يعالج أي منهما وحده on-chain heuristics أو أخطاء coin control. [1]

يتطلب التحقق من الادعاء implementation محددة لا الاسم فقط. يجب فحص feature negotiation وبناء epochs وstem peers وربط incoming edges والتحول stem/fluff وembargo timer وfallback مع peers غير المتوافقين وقياسات anonymity وlatency وسلوك partial deployment. [2]