باتت البلوكشين اليوم قادرة على الادعاء بثقة بأنها تملك الإمكانيات اللازمة لمنافسة البنية التحتية المالية التقليدية. فأنظمة الإنتاج الحالية تستطيع معالجة عشرات الآلاف من المعاملات في الثانية، مع تطورات نوعية مرتقبة في المستقبل القريب.
لكن، إلى جانب القدرة على معالجة المعاملات، تحتاج التطبيقات المالية إلى مستوى عالٍ من التنبؤ. عند إرسال معاملة—سواء كانت تداولًا، مزايدة في مزاد، أو تنفيذ خيار—يصبح وجود ضمان موثوق لموعد تنفيذ المعاملة ضرورة لعمل الأنظمة المالية. إذا تعرضت المعاملات لتأخيرات غير متوقعة (سواء بفعل فاعل أو بالصدفة)، تصبح العديد من التطبيقات غير قابلة للاستخدام. لكي تكون التطبيقات المالية على البلوكشين منافسة، يجب أن توفر السلسلة ضمانات إدراج قصيرة الأجل، بحيث إذا تم تقديم معاملة صالحة إلى الشبكة، يتم ضمان إدراجها بأسرع وقت ممكن.
على سبيل المثال، دفتر الأوامر على البلوكشين. تتطلب دفاتر الأوامر الفعّالة من صانعي السوق توفير السيولة باستمرار عبر الحفاظ على أوامر شراء وبيع الأصول المدرجة. التحدي الأساسي لصانعي السوق هو الحفاظ على فارق سعري ضيق (الفرق بين سعر الشراء والبيع) قدر الإمكان، دون التعرض للاختيار السلبي بتقديم أسعار غير متوافقة مع السوق. لتحقيق ذلك، يجب على صانعي السوق تحديث أوامرهم باستمرار لتواكب حالة السوق. على سبيل المثال، إذا أدى إعلان الاحتياطي الفيدرالي إلى ارتفاع أسعار الأصول، يحتاج صانعو السوق إلى الاستجابة الفورية بتحديث أوامرهم إلى السعر الجديد. إذا لم تهبط معاملات صانع السوق لتحديث أوامره فورًا، سيتكبد خسارة نتيجة قيام الموازنين بتنفيذ أوامره بأسعار قديمة. عندها سيضطر صانعو السوق إلى وضع فارق سعري أكبر لتقليل تعرضهم لمثل هذه الأحداث، مما يجعل منصات البلوكشين أقل تنافسية.
التنبؤ بإدراج المعاملات هو ما يمنح صانعي السوق ضمانات قوية بشأن قدرتهم على الاستجابة السريعة للأحداث خارج السلسلة والحفاظ على كفاءة الأسواق على البلوكشين.
السلاسل الحالية توفر ضمانات قوية فقط للإدراج النهائي، والذي يحدث خلال ثوانٍ. وبينما تكفي هذه الضمانات لتطبيقات مثل المدفوعات، إلا أنها ضعيفة جدًا لدعم فئة كبيرة من التطبيقات المالية حيث يحتاج المشاركون في السوق إلى التفاعل مع المعلومات في الوقت الفعلي. في دفتر الأوامر، ضمان إدراج صانع السوق "في الثواني القليلة القادمة" لا معنى له إذا تمكنت معاملات الموازنين من الهبوط في كتل سابقة. دون ضمانات إدراج قوية، يجب على صانعي السوق احتساب زيادة الاختيار السلبي من خلال توسيع الفارق السعري وتقديم أسعار أسوأ للمستخدمين. وهذا بدوره يجعل التداول على البلوكشين أقل جاذبية مقارنة بالمنصات الأخرى التي تقدم ضمانات أقوى.
لتحقيق رؤية البلوكشين كبنية تحتية حديثة لأسواق رأس المال، يجب معالجة هذه القضايا حتى تزدهر التطبيقات ذات القيمة العالية مثل دفاتر الأوامر.
تعزيز ضمان الإدراج للسلاسل الحالية لدعم هذه الحالات أمر صعب. بعض البروتوكولات تعتمد على عقدة واحدة ("القائد") يمكنها تحديد إدراج المعاملات في أي وقت. بينما يُبسط ذلك التحدي الهندسي لبناء سلسلة فعّالة، إلا أنه يخلق نقطة اختناق اقتصادية محتملة حيث يمكن لهؤلاء القادة استخراج قيمة. بشكل عام، خلال فترة انتخاب العقدة كقائد، يكون لديها سلطة كاملة على ما يتم إدراجه في الكتلة.
بالنسبة لسلسلة تتعامل مع أي نشاط مالي، يحتل القائد موقعًا مميزًا. إذا قرر هذا القائد عدم إدراج معاملة معينة، فإن الحل الوحيد هو الانتظار حتى يتم انتخاب قائد جديد مستعد لإدراج تلك المعاملة. في شبكة لا مركزية، يُحفز القادة لاستخراج القيمة، والمعروفة اصطلاحًا باسم MEV. يتجاوز MEV مجرد عمليات مثل تنفيذ تداولات AMM. حتى قدرة القائد على تأخير إدراج المعاملة لبضعة عشرات من المللي ثانية يمكن أن تحقق له ربحًا كبيرًا وتقلل من كفاءة التطبيقات الأساسية. دفتر أوامر يعطي الأولوية فقط لمعاملات مجموعة معينة من المتداولين يترك الجميع في وضع غير عادل. في أسوأ الحالات، قد يصبح القائد عدائيًا لدرجة أن المتداولين يتركون المنصة بالكامل.
مثال: إذا حدث رفع في سعر الفائدة وانخفض سعر ETH فورًا بنسبة %5، يهرع كل صانع سوق لإلغاء أوامره القائمة وإنشاء أوامر جديدة بالأسعار الجديدة. في نفس الوقت، يقدم كل موازن أمرًا لبيع ETH بالأوامر القديمة. إذا كان دفتر الأوامر يُدار ببروتوكول بقائد واحد، فإن القائد يمتلك قوة هائلة. يمكن للقائد ببساطة اختيار حجب كل عمليات إلغاء صانعي السوق، مما يسمح للموازنين بتحقيق أرباح ضخمة. أو بدلاً من الحجب المباشر، يمكن للقائد تأخير الإلغاءات حتى ينفذ الموازنون معاملاتهم. حتى يمكن للقائد إدراج معاملاته الخاصة للموازنة والاستفادة الكاملة من الفارق السعري.
أمام هذه الامتيازات، يصبح من غير المجدي لصانعي السوق المشاركة بنشاط؛ فكلما حدثت حركة في الأسعار قد يتم استغلالهم. تكمن المشكلة في أن القائد يتمتع بامتيازات زائدة بطريقتين أساسيتين: 1) يمكنه حجب معاملات الآخرين، و2) يمكنه رؤية معاملات الآخرين وتقديم معاملاته بناءً عليها. أي من هاتين المشكلتين قد تكون كارثية.
يمكننا تحديد المشكلة بدقة بالمثال التالي. مزاد به مزايدان، أليس وبوب، حيث أن بوب هو أيضًا القائد للكتلة التي يُجرى فيها المزاد. (وجود مزايدين فقط للتوضيح؛ نفس المنطق ينطبق بغض النظر عن عدد المزايدين.)
يقبل المزاد المزايدات خلال فترة إنتاج الكتلة، من الزمن t=0 إلى t=1. تقدم أليس مزايدة bA في الزمن tA ويقدم بوب مزايدة bB في الزمن tB > tA. بما أن بوب هو القائد للكتلة، يمكنه دائمًا ضمان أنه يتحرك أخيرًا. لدى أليس وبوب مصدر معلومات محدث باستمرار لسعر الأصل يمكنهم القراءة منه (مثل سعر منتصف التداول في منصة مركزية). في الزمن t، يكون هذا السعر pt. نفترض أنه في الزمن t، السعر المتوقع للأصل عند t=1 (عند انتهاء المزاد) هو دائمًا pt. قواعد المزاد بسيطة: من يقدم أعلى مزايدة من أليس وبوب يفوز بالمزاد ويدفع مزايدته.
إذا كان بوب قادرًا على حجب مزايدة أليس، ينهار المزاد. يمكن لبوب تقديم مزايدة صغيرة جدًا ويضمن الفوز بالمزاد لأنه لا توجد مزايدات أخرى. يؤدي ذلك إلى تصفية المزاد بعائد فعليًا صفر.
الحالة الأكثر تعقيدًا هي عندما لا يستطيع بوب حجب مزايدة أليس لكن يمكنه رؤية مزايدتها قبل أن يقدم مزايدته. في هذه الحالة، لدى بوب استراتيجية بسيطة: عند تقديم مزايدته، يتحقق فقط مما إذا كان ptB > bA. إذا كان الأمر كذلك، يقدم بوب مزايدة أعلى بقليل من bA، وإذا لم يكن كذلك لا يقدم مزايدة. باتباع هذه الاستراتيجية، يتعرض أليس للاختيار السلبي. المرة الوحيدة التي تفوز فيها أليس هي عندما يتغير السعر بحيث تصبح مزايدتها أعلى من القيمة المتوقعة للأصل. كلما فازت أليس بالمزاد، تتوقع خسارة المال وتكون أفضل حالًا بعدم المشاركة في المزاد من الأساس. مع اختفاء جميع المزايدين المنافسين، يمكن لبوب مرة أخرى تقديم مزايدة صغيرة جدًا والفوز بعائد فعليًا صفر.
الخلاصة: لا يهم كم يستغرق المزاد من الوقت. طالما يستطيع بوب حجب مزايدة أليس أو رؤيتها قبل تقديم مزايدته، فإن المزاد محكوم عليه بالفشل.
تنطبق نفس المبادئ من هذا المثال على أي بيئة تُتداول فيها الأصول بتردد عالي، سواء كان التداول الفوري، العقود الدائمة، أو منصة مشتقات: إذا كان هناك قائد يمتلك نفس القوة التي لدى بوب في هذا المثال، يمكن لهذا القائد أن يؤدي إلى انهيار السوق بالكامل. لكي تكون المنتجات على البلوكشين قابلة للاستخدام في هذه الحالات، يجب ألا تمنح القائد هذه الصلاحيات.
توضح القصة أعلاه صورة قاتمة للتداول على البلوكشين في أي بروتوكول بقائد واحد لا مركزي. ومع ذلك، تظل أحجام تداول منصات التبادل اللامركزي (DEX) على العديد من بروتوكولات القائد الواحد قوية، فما السبب؟
هناك عاملان عمليًا يواجهان المشكلات المذكورة أعلاه:
بينما حافظ هذان العاملان على عمل التمويل اللامركزي (DeFi)، إلا أنهما لن يكونا كافيين لكي تكون الأسواق على البلوكشين منافسة حقيقية لنظيراتها خارج السلسلة على المدى الطويل.
لكي يكون الشخص مؤهلًا كقائد على سلسلة ذات نشاط اقتصادي مهم، يتطلب ذلك كمية كبيرة من التخزين. إما أن يمتلك القائد كمية كبيرة من التخزين بنفسه أو يمتلك سمعة كافية ليقوم أصحاب الرموز بتفويض التخزين له. في كلتا الحالتين، غالبًا ما يكون مشغلو العقد الكبار كيانات معروفة وسمعتهم على المحك. بالإضافة إلى السمعة، يعني هذا التخزين أن هؤلاء المشغلين لديهم أيضًا حوافز مالية لنجاح سلاسلهم. لهذا السبب، لم نشهد استغلال القادة لقوتهم السوقية بالكامل كما هو موضح أعلاه—لكن هذا لا يعني أن هذه المشكلات ليست موجودة.
من ناحية أخرى، الاعتماد على حسن نية مشغلي العقد من خلال الضغط الاجتماعي والاعتماد على حوافزهم طويلة الأجل ليس أساسًا قويًا لمستقبل المالية. مع زيادة حجم النشاط المالي على البلوكشين، تزداد الأرباح المحتملة للقادة. وكلما زاد هذا الاحتمال، أصبح الضغط على الطبقة الاجتماعية للحفاظ على سلوك القادة ضد مصالحهم الفورية أصعب.
ثانيًا، مدى قدرة القادة على استخدام قوتهم السوقية يتراوح من السلوك الحميد إلى انهيار السوق بالكامل. يمكن لمشغلي العقد دفع حدود استغلال قوتهم لتحقيق أرباح أعلى. ومع تجاوز بعض المشغلين حدود المقبول، يتبعهم الآخرون بسرعة. قد يبدو سلوك عقدة فردية غير مهم، لكن عندما يتغير الجميع، يكون التأثير واضحًا.
أفضل مثال على هذه الظاهرة هو ألعاب التوقيت: عندما يسعى القادة لتأخير إعلان الكتلة حتى آخر لحظة مع بقائها صالحة للبروتوكول لتحقيق مكافآت أعلى. يمكن أن يؤدي ذلك إلى أوقات كتل أطول وتخطي بعض الكتل عندما يكون القائد شديد العدوانية. رغم أن ربحية هذه الاستراتيجيات كانت معروفة على نطاق واسع، إلا أن القادة امتنعوا عن اتباعها بدافع كونهم أوصياء جيدين للسلسلة. ومع ذلك، كان هذا توازنًا اجتماعيًا ضعيفًا. بمجرد أن بدأ مشغل عقدة واحدة اتباع هذه الاستراتيجيات لتحقيق مكافآت أعلى دون عواقب، انضم إليه الآخرون بسرعة. ألعاب التوقيت هي مجرد مثال على كيفية زيادة القادة لأرباحهم دون استغلال كامل لقوتهم السوقية. هناك العديد من الإجراءات الأخرى التي يمكن للقادة اتخاذها لزيادة مكافآتهم على حساب التطبيقات. قد تكون هذه الإجراءات قابلة للتعامل بالنسبة للتطبيقات بشكل منفرد، لكن في النهاية يصل الأمر إلى نقطة تفوق فيها تكلفة العمل على البلوكشين الفوائد.
العامل الآخر الذي حافظ على عمل DeFi هو انتقال التطبيقات للمنطق المهم خارج السلسلة ونشر النتائج فقط على البلوكشين. على سبيل المثال، أي بروتوكول يحتاج إلى إجراء مزاد سريع يقوم بذلك خارج السلسلة. غالبًا ما تدير هذه التطبيقات آلياتها المطلوبة على مجموعة محددة من العقد لتجنب مشكلات القادة العدائيين. على سبيل المثال، يقوم UniswapX بإجراء مزاده الهولندي لملء التداولات على Ethereum mainnet خارج السلسلة، وبالمثل يقوم Cowswap بإجراء مزاده الدفعي خارج السلسلة. رغم أن هذا الأمر يعمل لصالح التطبيقات، إلا أنه يضع الطبقة الأساسية وقيمة البناء على البلوكشين في وضع حساس. عالم يكون فيه منطق التنفيذ للتطبيقات خارج السلسلة يجعل الطبقة الأساسية مخصصة فقط للتسوية. أحد أهم مزايا DeFi هو القابلية للتكامل. في عالم يتم فيه كل التنفيذ خارج السلسلة، تعيش هذه التطبيقات في بيئات معزولة بطبيعتها. الاعتماد على التنفيذ خارج السلسلة يضيف أيضًا افتراضات جديدة إلى نماذج الثقة لهذه التطبيقات. بدلاً من الاعتماد فقط على أن السلسلة الأساسية تعمل، يجب أن تكون البنية التحتية خارج السلسلة متاحة أيضًا لكي تعمل التطبيقات.
لمعالجة هذه القضايا، هناك خاصيتان يجب أن يحققها البروتوكول: إدراج المعاملات بشكل ثابت وقواعد ترتيب ثابتة، وخصوصية المعاملات قبل التأكيد (للتعريف الدقيق لهذه الخصائص ومناقشة موسعة، راجع https://arxiv.org/abs/2509.23984، خاصة التعريفين 9 و11).
نلخص الخاصية الأولى بمقاومة الحجب قصيرة الأجل. حيث يكون البروتوكول مقاومًا للحجب قصير الأجل إذا كان أي معاملة تصل إلى عقدة صادقة يتم ضمان إدراجها في الكتلة التالية الممكنة:
مقاومة الحجب قصيرة الأجل: أي معاملة صالحة تصل إلى أي عقدة صادقة في الوقت المناسب، سيتم إدراجها بالتأكيد في الكتلة التالية الممكنة.
نفترض أن البروتوكول يعمل على ساعة ثابتة حيث يتم إنتاج كل كتلة في أوقات محددة، مثل كل 100ms. حينها نريد ضمان أنه إذا وصلت معاملة إلى عقدة صادقة في t=250ms، سيتم إدراجها في الكتلة المنتجة عند t=300ms. يجب ألا يكون للخصم سلطة انتقائية لإدراج معاملات معينة واستبعاد أخرى. روح هذا التعريف أن المستخدمين والتطبيقات يجب أن يكون لديهم طريقة موثوقة للغاية لإدراج المعاملات في أي وقت. لا ينبغي أن يؤدي سقوط حزم البيانات من عقدة واحدة، سواء بسبب سوء النية أو خلل تشغيلي بسيط، إلى عدم تنفيذ تداول.
بينما يتطلب هذا التعريف ضمانات إدراج للمعاملات التي تصل لأي عقدة صادقة، إلا أن تحقيق ذلك عمليًا قد يكون مكلفًا جدًا. الميزة المهمة هي أن البروتوكول يجب أن يكون قويًا بحيث تتصرف نقاط الدخول للبلوكشين بطريقة متوقعة للغاية وسهلة الفهم. بروتوكول القائد الواحد غير المصرح به لا يحقق هذه الخاصية بوضوح، لأنه إذا كان القائد الوحيد في أي وقت متعطلًا، فلا توجد وسيلة أخرى لإدراج المعاملة. ومع ذلك، حتى مجموعة من أربع عقد يمكنها ضمان إدراج المعاملات في كل خانة تحسن بشكل كبير خيارات المستخدمين والتطبيقات لإدراج المعاملات. من المفيد التضحية ببعض الأداء لصالح بروتوكول يسمح للتطبيقات بالازدهار بشكل موثوق. لا يزال هناك عمل للعثور على التوازن المثالي بين القوة والأداء، لكن الضمانات من البروتوكولات الحالية ليست كافية.
بما أن البروتوكول يمكنه ضمان الإدراج، فإن الترتيب يأتي تلقائيًا. البروتوكولات حرة في استخدام أي قاعدة ترتيب حتمية تضمن ترتيبًا ثابتًا. أبسط حل هو الترتيب حسب أولوية الرسوم أو السماح للتطبيقات بترتيب المعاملات التي تتفاعل مع حالتها. لا يزال تحديد الطريقة المثلى لترتيب المعاملات مجالًا نشطًا للبحث، لكن على أي حال، قواعد الترتيب لا تهم إلا إذا تم إدراج المعاملات.
بعد مقاومة الحجب قصيرة الأجل، الخاصية الأهم التالية هي أن يوفر البروتوكول شكلًا من الخصوصية نسميه الإخفاء.
الإخفاء: لا يعرف أي طرف، باستثناء العقدة التي تم تقديم المعاملة إليها، أي معلومات عن المعاملة قبل أن يتم تأكيد إدراجها من قبل البروتوكول.
قد يسمح البروتوكول الذي يحقق الإخفاء للعقد برؤية جميع المعاملات المقدمة إليها بشكل واضح، لكنه يتطلب من باقي البروتوكول أن يكون أعمى حتى ينتهي الإجماع ويُحدد ترتيب المعاملة في السجل النهائي. على سبيل المثال، قد يستخدم البروتوكول تشفير توقيت بحيث يتم إخفاء محتوى الكتلة بالكامل حتى موعد محدد؛ أو قد يستخدم تشفير العتبة بحيث يتم فك تشفير الكتلة بمجرد موافقة لجنة على أنها مؤكدة بشكل لا رجعة فيه.
هذا يعني أن العقدة قد تسيء استخدام المعلومات من أي معاملة مقدمة إليها، لكن باقي البروتوكول لا يعرف محتوى ما يتوافقون عليه حتى بعد التنفيذ. بحلول الوقت الذي يتم فيه كشف معلومات المعاملة لباقي الشبكة، تكون المعاملة قد تم ترتيبها وتأكيدها بالفعل، فلا يمكن لأي طرف آخر تنفيذ تداول مسبق. ليكون هذا التعريف مفيدًا، يجب أن يكون بإمكان عدة عقد إدراج المعاملات في أي خانة.
السبب في عدم اعتماد المفهوم الأقوى حيث يعرف المستخدم فقط أي شيء عن معاملته قبل تأكيدها (مثل تجمعات الذاكرة المشفرة) هو أن البروتوكول يحتاج إلى خطوة لتصفية المعاملات غير المرغوب فيها. إذا كانت محتويات المعاملة مخفية بالكامل عن الشبكة، فلا توجد طريقة لتصفية المعاملات غير المفيدة من المعاملات المهمة. الحل الوحيد هو تسريب بعض البيانات غير المخفية مثل عنوان دافع الرسوم الذي يتم خصمه بغض النظر عن صلاحية المعاملة. لكن هذه البيانات قد تسرب ما يكفي من المعلومات ليستغلها الخصم. لذا نفضل أن تكون لدى عقدة واحدة رؤية كاملة للمعاملة، لكن لا توجد أي رؤية لباقي العقد. وهذا يعني، ليكون هذا المفهوم مفيدًا، يجب أن يكون لدى المستخدم نقطة دخول واحدة صادقة لإدراج المعاملة في كل خانة.
البروتوكول الذي يحقق مقاومة الحجب قصيرة الأجل والإخفاء يوفر قاعدة مثالية لبناء التطبيقات المالية. بالعودة إلى مثال محاولة إجراء مزاد على البلوكشين، تعالج هاتان الخاصيتان مباشرة الطرق التي يمكن لبوب من خلالها التسبب في انهيار السوق. لا يمكن لبوب حجب مزايدة أليس ولا الاستفادة منها لتقديم مزايدته، مما يعالج المشكلتين 1) و2) من المثال السابق. (للمزيد من التفاصيل، راجع هذه الورقة الحديثة.)
مع مقاومة الحجب قصيرة الأجل، أي شخص يقدم معاملة سواء كانت تداولًا أو مزايدة في مزاد يضمن إدراجًا فوريًا. يمكن لصانعي السوق تغيير أوامرهم؛ يمكن للمزايدين تقديم مزايدات بسرعة؛ يمكن تنفيذ التصفية بكفاءة. يمكن للمستخدمين التأكد من أن أي إجراء يتخذونه سيتم تنفيذه فورًا. سيتيح ذلك بناء الجيل القادم من التطبيقات المالية الحقيقية منخفضة التأخير بالكامل على البلوكشين. لكي تتنافس البلوكشين حقًا مع البنية التحتية المالية الحالية—وتتفوق عليها—نحتاج إلى حل أكثر من مجرد القدرة على معالجة المعاملات.
الآراء الواردة هنا تخص الأشخاص العاملين في AH Capital Management, L.L.C. ("a16z") المذكورين ولا تعبر عن آراء a16z أو الشركات التابعة لها. تم الحصول على بعض المعلومات الواردة هنا من مصادر خارجية، بما في ذلك شركات المحفظة الاستثمارية المدارة من قبل a16z. رغم أن المصادر يُعتقد بأنها موثوقة، لم تقم a16z بالتحقق من هذه المعلومات بشكل مستقل ولا تقدم أي ضمانات بشأن دقتها الحالية أو المستمرة أو ملاءمتها لأي حالة معينة. بالإضافة إلى ذلك، قد يتضمن هذا المحتوى إعلانات طرف ثالث؛ لم تقم a16z بمراجعة هذه الإعلانات ولا تؤيد أي محتوى إعلاني وارد فيها.
يجب عليك استشارة مستشاريك بشأن هذه الأمور. الإشارات إلى أي أوراق مالية أو أصول رقمية هي لأغراض توضيحية فقط، ولا تشكل توصية استثمارية أو عرضًا لتقديم خدمات استشارية استثمارية. علاوة على ذلك، لا يستهدف هذا المحتوى ولا يُقصد استخدامه من قبل أي مستثمرين أو مستثمرين محتملين، ولا يمكن الاعتماد عليه في أي قرار للاستثمار في أي صندوق تديره a16z. (سيتم تقديم عرض للاستثمار في صندوق a16z فقط من خلال مذكرة الطرح الخاصة، اتفاقية الاشتراك، وغيرها من الوثائق ذات الصلة ويجب قراءتها بالكامل.) أي استثمارات أو شركات محفظة تم ذكرها أو الإشارة إليها أو وصفها ليست ممثلة لجميع الاستثمارات في المركبات المدارة من قبل a16z، ولا يمكن ضمان أن تكون الاستثمارات مربحة أو أن الاستثمارات المستقبلية ستحمل نفس الخصائص أو النتائج. قائمة الاستثمارات التي قامت بها صناديق a16z (باستثناء الاستثمارات التي لم تقدم الشركة المصدرة إذنًا لـ a16z بالإفصاح عنها علنًا وكذلك الاستثمارات غير المعلنة في الأصول الرقمية المتداولة علنًا) متاحة على https://a16z.com/investment-list/.
يتحدث المحتوى فقط اعتبارًا من التاريخ المشار إليه. أي توقعات أو تقديرات أو تنبؤات أو أهداف أو آفاق أو آراء معبر عنها في هذه المواد قابلة للتغيير دون إشعار وقد تختلف أو تتعارض مع آراء الآخرين. يرجى مراجعة https://a16z.com/disclosures/ لمزيد من المعلومات المهمة.
تم إعادة نشر هذا المقال من [a16zcrypto]. جميع الحقوق محفوظة للمؤلف الأصلي [@PGarimidi،@jneu_net، و @MaxResnick]. إذا كان هناك اعتراض على إعادة النشر، يرجى التواصل مع فريق Gate Learn، وسيتم التعامل مع الأمر بسرعة.
إخلاء مسؤولية: الآراء والتوجهات الواردة في هذا المقال تعبر عن رأي الكاتب فقط ولا تمثل أي نصيحة استثمارية.
تتم ترجمة المقالات إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر خلاف ذلك، يُحظر نسخ أو توزيع أو اقتباس المقالات المترجمة.





