الآراء والافتراضات الأساسية الواردة في هذه القطعة:

• يجب أن يكون بعض الخصوصية في شبكات البلوكتشين ضروريًا، وليس مجرد شيء لطيف
• طبيعة سلاسل الكتل الشفافة الحالية عامل مانع كبير للاعتماد الأوسع
• سيحتاج المستخدمون المختلفون وحالات الاستخدام المختلفة إلى مستويات مختلفة من الخصوصية. ليس كل المشاكل تحتاج إلى حل بنفس الأداة.

هل يهتم المستخدمون الأفراد بالخصوصية؟

نعم، ولكن البعض أكثر من الآخرين.

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

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

سؤال آخر مهم هو: من يرغب المستخدمون في الخصوصية منه؟

1. مستخدمون آخرون في الشبكة والمراقبون الخارجيون
2. الأطراف الثالثة والوسطاء الذين يسهلون الخدمة
3. الحكومات والهيئات الحكومية والمراقبة الجماعية

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

كيف نحدد "الخصوصية"؟

الخصوصية ليست سرية. الأمر الخاص هو شيء لا يرغب الشخص في أن يعرفه العالم بأسره، ولكن الأمر السري هو شيء لا يرغب في أن يعرفه أي شخص. الخصوصية هي القوة للكشف عن النفس انتقائياً أمام العالم - ميثاق السايفربانك

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

بعض الأسئلة الرئيسية المتعلقة بالخصوصية هي:

• ما يمكن الكشف عنه ولمن إذا ما تم الرغبة في ذلك؟
• من لديه السلطة للكشف عن المعلومات؟
• ما يجب أن يكشف ولمن يجب أن يكشف لضمان عمل النظام؟
• ما هي الضمانات المتاحة بأن كل ما هو خاص اليوم سيبقى كذلك غدًا؟

استنادًا إلى هذه الأسئلة، يمكننا تلخيصها في جملة واحدة:

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

هل نحتاج إلى مصطلحات جديدة؟

بالنظر إلى ما سبق - هل "الخصوصية" مصطلح سيء لما نحاول تحقيقه؟ ربما نعم، ربما لا. يعتمد ذلك على كيفية اقترابك منه.

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

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

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

ومع ذلك، سنلتزم بمصطلح الخصوصية في هذا المنصب لتجنب الارتباك غير الضروري.

كيف تختلف الخصوصية في شبكات الويب 2 عن شبكات البلوكتشين؟

معظم مستخدمي الإنترنت على دراية بـ ويب 2 "الخصوصية". بياناتنا مشفرة أثناء النقل (حتى 95٪ من كل حركة مرور اليوموهي محمية من المستخدمين الآخرين، ولكنها مشتركة مع الوسطاء الموثوق بهم ومزودي الخدمات. بعبارة أخرى، فإن 'الخصوصية' (من المستخدمين الآخرين) تأتي من الثقة في وسيط.

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

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

لماذا من الصعب تحقيق الخصوصية في شبكات البلوكتشين؟

هناك طريقتان لتحقيق الخصوصية لشبكات البلوكتشين: الثقة (الوسيطة) أو الثقة المنخفضة (غير الوسيطة) الخصوصية.

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

الخصوصية الموثوقة في شبكات البلوكتشين

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

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

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

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

(نحن نضمن تضمين البلوكتشين المرخص في الفئة الموثوقة، ولكن جميع الحلول الأخرى تتعلق بالبلوكتشين غير المرخص).

الخصوصية المتقلصة في شبكات البلوكتشين الموثوقة

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

الحلول الحالية تتركز بشكل رئيسي حول حالات الاستخدام المتخصصة، مثل:

• مالي: يهدف التحويلات الخاصة والمدفوعات والتبادلات الخاصة إلى إخفاء الهوية والمدخلات و / أو النتائج (من أرسل ما، وكم، وإلى من). يشمل التناقض بين الحلول المختلفة حمامات السباحة المحمية متعددة الأصول مقابل المفردة وكم منها هو خاص. الأمثلة هنا تشملزيكاش،نامادا، و Penumbra.
• الهوية: الخصوصية غير قابلة للتفاوض لأي حل يتطلب منا ربط هويتنا خارج السلسلة بهويتنا على السلسلة أو محاولة تخزين مستندات الهوية على السلسلة. هناك عدة محاولات من قبل القطاع الخاص (مثل دليل جواز السفروHolonymبالإضافة إلىزيادة الاهتمام من قبل الحكومات لدعم حلول الهوية الرقمية التي تحافظ على الخصوصية.
• الحكم: فكرة التصويت الخاص على السلسلة هي إخفاء من صوت ما والاحتفاظ بالإجمالي الخاص حتى نهاية الاقتراع بحيث لا يؤثر على قرار التصويت لأي فرد. يقوم الرسم البياني أدناه بسرد بعض الأمثلة مع ميزات متنوعة وافتراضات الثقة:

• نظرة عامة على بعض الحلول القائمة (المصدر)

العديد من الحالات الاستخدامية تعتمد على حالة مشتركة، ويصبح الأمر أكثر تحدياً عند محاولة توسيع الخصوصية المحدودة للثقة إلى هذه الحالات الاستخدامية ذات الأغراض العامة.

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

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

كيف يمكننا تقييم الحلول المختلفة؟

بينما الهدف النهائي واضح، إلا أن الطريق للوصول إليه طويل. في الوقت نفسه، نحتاج إلى أطر لتقييم الحلول الحالية والتنازلات التي تقدمها. نحن نعتقد أن مساحة التنازل يمكن تقسيمها إلى ثلاث فئات رئيسية:

1. ما هو الخاص - أنواع مختلفة من الخصوصية المتعلقة بتقنية البلوكتشين:

1. المدخلات الخاصة (الرسائل)
2. المخرجات الخاصة (تغييرات الدولة)
3. الأطراف الخاصة
   1. المستخدمين
   2. وظيفة
   3. برنامج

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

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

1. القابلية للبرمجة - ماذا يمكنك استخدام الخصوصية ل؟

تركز هذه الفئة على قابلية برمجة الحساب الخاص وحدوده:

• هل يمكنك الحساب على البيانات المشفرة؟ هل هناك أي قابلية للتركيب بين البرامج الخاصة؟
• هل يمكن للدول الخاصة والعامة التفاعل بأي شكل من الأشكال؟ ما هي القيود والمفاضلات لهذا؟
• ما هي الحدود المتاحة للبرامج المعقدة (حدود الغاز، التعبير، الخ)؟

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

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

1. قوة ضمانات الخصوصية - ما مدى موثوقية الخصوصية؟

السؤال الأساسي هو: إلى أي مدى يمكننا التأكد من أن كل ما هو خاص اليوم سيبقى كذلك في المستقبل (الخصوصية الأمامية) وما هي الضمانات التي تدعم ذلك؟

هذا يشمل أمور مثل:

• ما هي المعلومات (إن وجد) التي يحتاج المستخدم إلى مشاركتها مع طرف ثالث موثوق أو وسيط؟ ما هي الضمانات المتوفرة بأن الوسيط سيتصرف كما هو متوقع؟
• ما هو حجم المجموعة المحمية؟ (شبكة > متعددة السلاسل (L1 / L2) > تطبيق > أصل واحد)
• ما هي مخاطر الرقابة؟ (الخصوصية على مستوى التطبيق مقابل الخصوصية على مستوى الطبقة الأساسية)
• هل نظام الإثبات مقاوم للكمون؟
• هل يتطلب نظام الإثبات إعداد موثوق؟ إذا كان الأمر كذلك، كم عدد المشاركين في ذلك؟
• هل يتمتع النظام بالخصوصية كافتراضي، أم أن هناك حوافز أخرى لتعزيز عدد التفاعلات داخل المجموعة المحمية؟

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

كيف يتم ربط إطار التضحية هذا بالأسئلة الأربع المطروحة في بداية المقالة؟

• ما الذي يمكن الكشف عنه ولمن إذا رغب الشخص في ذلك؟ تتعلق هذه السؤال بما هو خاص وقابلية البرمجة. إذا كانت جميع المعلومات عامة بشكل افتراضي، فإن الاختيار الوحيد الذي يملكه المستخدمون المتعلق بالخصوصية هو ما إذا كانوا يرغبون في المشاركة في الشبكة أم لا. نحتاج إلى الخصوصية بشكل افتراضي لدينا الخيار في الكشف (على الأقل الخصوصية من المستخدمين الآخرين/المراقبين الخارجيين). يمكن تمثيل القابلية للبرمجة على أنها قواعد كشف مفصلة، أي من لمن، متى، ماذا، وكيف يتم الكشف عن المعلومات (وإلغاؤها).
• من لديه القدرة على الكشف عن المعلومات؟ يتعلق ذلك في الغالب بقوة ضمانات الخصوصية ويكون أقوى عندما يكون للمستخدم فقط القدرة على مشاركة المعلومات (الخصوصية المحدودة للثقة).
• ما يجب الكشف عنه وإلى من يجب كشفه ليعمل النظام؟ يتعلق بشكل أساسي بالقدرة على البرمجة. في الواقع، تحتاج إلى الكشف عن أقل قدر ممكن من المعلومات بينما لا تزال قادرًا على الحساب على حالة مشتركة، ولديك قابلية التركيب بين برامج مختلفة، وتكون قادرًا على بناء علاقات ثقة جديدة. في الواقع، ليس هذا هو الحال (على الأقل في الوقت الحالي) ويتعين عمل بعض التنازلات.
  • في الواقع، يمكن أن توفر البراهين الصفرية الاستثنائية تحولا نمطيا لهذا الجانب من الخصوصية بما أنها تمكننا من إثبات صحة شيء ما دون الحاجة إلى الكشف عن معلومات زائدة. على سبيل المثال، عند استئجار شقة، نحتاج إلى إثبات لصاحب الشقة المحتمل أن لدينا دخل كافٍ لدفع الإيجار. اليوم، يتطلب هذا منا إرسال كامل كشف حسابنا البنكي مما يكشف الكثير من المعلومات الإضافية. في المستقبل، قد يتم بناء هذا العلاقة الثقة على أساس براهين صفرية موجزة بدلاً من ذلك.
• ما هي الضمانات الموجودة بأن كل ما هو خاص اليوم سيبقى كذلك غدا؟ يرتبط مفهوم "الخصوصية الأمامية" في الغالب بقوة ضمانات الخصوصية. ستساعد المجموعات المحمية الأكبر في ذلك وتجعل من الصعب على المراقبين الخارجيين استخراج المعلومات. يمكن أن يساعد وضع ثقة أقل في الوسطاء ، ولكن ليس بالضرورة لأنه حتى إذا كان المستخدمون يتحكمون بشكل كامل في بياناتهم ، فقد تتسرب مفاتيحهم ، أو يمكن الكشف عن البيانات عن غير قصد ، أو يمكن نسخ البيانات التي تم الكشف عنها. لا يزال هذا المجال غير مستكشف نسبيا وغير مدروس ولكنه سيزداد أهمية مع اعتماد الخصوصية في شبكات blockchain على نطاق واسع.

ملخص

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

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

في عالم مثالي، يكون لدى المستخدمين تعبير كامل عن ما هو خاص ولمن، بالإضافة إلى ضمانات قوية بأن ما يتم برمجته ليكون خاصًا يبقى كذلك. سنلقي نظرة أقرب على التقنيات المختلفة التي تمكّن هذا وتجاربها في الجزء الثاني من سلسلة الخصوصية لدينا.

سيكون الانتقال نحو الحوسبة الخاصة للأغراض العامة على سلاسل الكتل طويلة وصعبة ، ولكنه يستحق ذلك في النهاية.

تنصل:

1. تمت إعادة طبع هذه المقالة من [توازن], العنوان الأصلي [ماذا نقصد فعلاً عندما نتحدث عن الخصوصية في شبكات البلوكتشين (ولماذا من الصعب تحقيقها)؟], جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [Hannes Huitula]. إذا كان هناك اعتراضات على هذا النشر المطبعي، يرجى التواصل مع بوابة تعلم فريق ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية عن الضرر: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالات إلى لغات أخرى من قبل فريق Gate Learn. إلا إذا ذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة محظور.