Address Clustering

تستخدم آنا عناوين جديدة لمبالغ تستلمها في أوقات مختلفة، ثم تدفع من محفظتها لمتجر. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. يرى المحلل حركة الأموال، لكن عليه الفصل بين سؤالين: ما الأموال التي أُنفقت، وأي العناوين قد تتحكم بها الجهة نفسها؟ تجيب دفعة المتجر عن السؤال الأول. ولا تكفي وحدها لوضع آنا والمتجر في مجموعة واحدة. تبحث Address Clustering عن قرائن أخرى، مثل إنفاق عدة مبالغ مستلمة معًا. لذا يعرض مخطط المدفوعات روابط معاملات حقيقية، بينما تضيف المجموعات الملونة تفسيرًا. هذا الفرق أساسي عند قراءة هذه الخرائط. [1] [5]

توجد الأموال المستلمة سابقًا على هيئة UTXO، أي مخرجات معاملات لم تُنفق بعد. يسجل كل مخرج مبلغًا والشروط التي يجب استيفاؤها لإنفاقه. يشير المدخل الجديد إلى مخرج سابق محدد، لا إلى خانة عامة تسمى «عنوان المرسل». يبحث البرنامج عن scriptPubKey الأصلي، أي شروط إنفاق المخرج. يمثل العنوان هذه الشروط بطريقة مريحة في الأنواع المدعومة؛ وليس لكل سكربت عنوان معتاد. يجب أن يوضح الشرح الدقيق هل يجمع عناوين أم سكربتات، وما الشبكة ونطاق الكتل. تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. ولا يتحول المعرّف التقني بذلك إلى هوية إنسان. [4] [6]

تفترض Common-Input Ownership Heuristic تحكمًا مشتركًا في عدة مدخلات للمعاملة. أما تحديد change فخطوة أخرى: تبحث عن المخرج الذي يعيد الباقي إلى الدافع بعد الدفع ورسوم المعاملة. إذا صح التقدير، فقد يربط عنوان الباقي الجديد لآنا بمبالغها السابقة. وإذا عُدّت دفعة المتجر change بالخطأ، فستُلحق أموال الغير. وجود مخرجين لا يحدد دورهما وحده؛ فقد يكونان لمستلمين مختلفين أو تحويلين بين محافظ الشخص نفسه. وحتى العنوان الذي لم يظهر سابقًا لا يثبت وحده أنه للدافع. [1] [3]

قد يكون المبلغ المقرّب أو نوع السكربت أو إعادة استخدام عنوان قرينة، لا قانونًا ثابتًا. تحديث المحفظة قد يبني المعاملات بشكل مختلف ويجعل نموذجًا قديمًا يخطئ. يتيح CoinJoin مشاركة عدة أشخاص في معاملة، وفي Payjoin وفق BIP 78 يستطيع المستلم إضافة مدخلاته الخاصة. ولا تتطلب المشاركة مخرجات متساوية المبالغ. لذلك لا يمكن ضمان الدقة التاريخية لمعاملات اليوم من دون تقييم جديد. ومن المهم أيضًا معرفة الحالات التي لا يقدم فيها الأسلوب أي توقع. [2] [3]

لنتصور مجموعتين منفصلتين من العناوين. قد يدمجهما رابط خاطئ واحد، وينشر الخطأ إلى جميع أعضائهما. تستخدم البرامج غالبًا union-find، وهي بنية بيانات لتتبع المجموعات المتصلة، كي تدمجها بسرعة. لكن صورتها المعتادة لا تحذف رابطًا قديمًا وتقسم النتيجة تلقائيًا على نحو صحيح. ولتحليل قابل للمراجعة، تتمثل التوصية العملية في حفظ المعاملات والروابط الفردية ونسخ القواعد، لا القائمة النهائية فقط. هذا استنتاج من انتشار الأخطاء الموصوف في البحث: التصحيح قد يحتاج إلى إعادة الحساب، لا مجرد تغيير اسم المجموعة. [2]

يدرس Malte Möser وArvind Narayanan منع cluster collapse، أي الاندماج الخاطئ لمجموعات كثيرة في مجموعة ضخمة. يرفض constrained union-find لديهما دمج مجموعتين يربطهما مخرج متوقع أنه دفعة. في مثال آنا، قد يمنع تقدير «إنها تدفع للمتجر» جمع الطرفين لاحقًا. لكن هذه الحماية لا تعرف الحقيقة بصورة مستقلة: فهي تعتمد على توقع الدفعة وقد ترفض روابط صحيحة. لذلك لا يعني انخفاض عدد عمليات الدمج تلقائيًا صورة كاملة أو خالية من الأخطاء للمالكين. [2]

وضع اسم منصة تداول على عنوان واحد وتعميم الاسم على cluster كامل خطوتان مختلفتان. يحتاج الوسم إلى مصدر وفترة صلاحية ومسار انتشار قابل للتتبع. وقد تخدم المجموعة التي تتحكم بها المنصة عملاء كثيرين. كذلك لا ينبغي أن يعتمد التحقق من النموذج فقط على بيانات أنتجها الافتراض نفسه. يجب تقييم الدمج الخاطئ والروابط الفائتة وتغطية العينة بشكل منفصل. كثرة العناوين الموسومة لا تضمن وحدها صحة نسبتها. [1] [2]

قد تنقل آنا أموالًا بين محفظتين تملكهما. إذا لم يربطهما النموذج، فقد يحسب الحركة دفعة بين جهتين مختلفتين. يمكن لتجميع أفضل أن يتعرف عليها كنقل داخلي، أو self-churn، فينخفض حجم المدفوعات المقدّر من دون تغير تاريخ البلوكشين. وبالمثل، يتكون رصيد المجموعة من UTXO التي لم تُنفق بعد عند كتلة محددة؛ جمع كل المبالغ المستلمة سابقًا سيشمل أموالًا أُنفقت. عند مقارنة الرسوم، تحقق من التاريخ ونسخة النموذج والوسوم والنقطة الزمنية للبيانات. [1] [2]