SNARK کی کارکردگی کی پیمائش: سامنے والے حصے، بیک اینڈ اور مستقبل

A SNARK (Succinct Non-interactive Arguments of Knowledge) بلاکچین اسکیل ایبلٹی (مثلاً، L2 رول اپ) اور رازداری کے لیے ایک اہم کرپٹوگرافک پرائمیٹو فائنڈنگ ایپلی کیشنز ہے۔ SNARKs کسی کو ناقابل اعتماد تصدیق کنندہ کو ثابت کرنے دیتے ہیں۔ V (مثال کے طور پر، Ethereum blockchain) کہ وہ کچھ ڈیٹا جانتے ہیں (مثال کے طور پر، درست لین دین کا ایک بیچ)۔ اس کو ثابت کرنے کا ایک سادہ طریقہ یہ ہوگا کہ ڈیٹا کو بھیجیں۔ V، جو اس کے بعد براہ راست اس کی درستگی کی جانچ کر سکتا ہے۔ ایک SNARK وہی حاصل کرتا ہے، لیکن اس کے لیے بہتر اخراجات کے ساتھ V. خاص طور پر، ایک SNARK ثبوت خود ڈیٹا پر مشتمل سادہ لوح سے چھوٹا ہونا چاہیے۔ (مزید تفصیل کے لیے میری نصابی کتاب کا مسودہ دیکھیں، ثبوت، دلائل، اور صفر علم. SNARKs کے تعارف کے لیے، سارہ میکلی جانز دیکھیں پریزنٹیشن a16z کرپٹو پر سمر ریسرچ سیریز.)

SNARKs کے لیے تصدیقی اخراجات مختلف ہو سکتے ہیں، لیکن اچھی طرح سمجھے جاتے ہیں اور اکثر کافی اچھے ہوتے ہیں۔ مثال کے طور پر، PlonK ثبوت کے بارے میں قیمت 290,000 گیس Ethereum پر تصدیق کرنے کے لیے، جبکہ StarkWare کے ثبوتوں کی قیمت تقریباً 5 ملین گیس ہے۔ SNARKs ممکنہ طور پر متنوع سیٹنگز میں لاگو ہوتے ہیں یہاں تک کہ بلاک چینز سے باہر بھی - مثال کے طور پر تیز لیکن ناقابل اعتماد کے استعمال کو فعال کرنا سرورز اور ہارڈ ویئر. 

لیکن چونکہ SNARK کی توثیق عام طور پر سستی ہوتی ہے، اس لیے قابل اطلاق ہونے کے اہم عامل SNARK prover کے اخراجات ہیں۔ P. اس پوسٹ میں، میں وضاحت کرتا ہوں کہ ان اخراجات کا اندازہ کیسے لگایا جائے تاکہ یہ معلوم کیا جا سکے کہ SNARKs کا استعمال کب مناسب ہے، اور SNARKs مستقبل میں کیسے بہتر ہو سکتے ہیں۔ یہ بات قابل غور ہے کہ یہ ایک تیزی سے حرکت کرنے والی جگہ ہے، اور اس پوسٹ میں زیر بحث کئی پروجیکٹس فعال طور پر اپنی کارکردگی کو بہتر بنا رہے ہیں۔

لیکن پہلے: SNARKs کو کیسے تعینات کیا جاتا ہے۔

SNARK کی تعیناتی میں ایک ڈویلپر عام طور پر کمپیوٹر پروگرام لکھتا ہے۔ ψ جو ڈیٹا کو ان پٹ کے طور پر لیتا ہے۔ w یہ کہنے والا دعویٰ کرتا ہے کہ وہ جانتا ہے (w کے لئے ہے گواہی)، اور اسے چیک کرتا ہے۔ w درست ہے. مثال کے طور پر، رول اپ میں، پروگرام چیک کرے گا کہ تمام لین دین w ڈیجیٹل طور پر دستخط شدہ ہیں، کسی بھی اکاؤنٹ کے بیلنس کو صفر سے نیچے نہ آنے دیں، وغیرہ۔ پروگرام ψ پھر a کے ذریعے کھلایا جاتا ہے۔ SNARK فرنٹ اینڈ جو اسے ایک ایسے فارمیٹ میں مرتب کرتا ہے جو SNARK ٹیکنالوجی کے استعمال کے لیے زیادہ قابل عمل ہے۔ اس SNARK دوستانہ فارمیٹ کو کہا جاتا ہے۔ درمیانی نمائندگی (IR)۔ 

عام طور پر، IR کسی قسم کی سرکٹ کی اطمینان بخش مثال ہے جو اس کے برابر ہے ψ. اس کا مطلب ہے کہ سرکٹ C ڈیٹا ان پٹ کے طور پر لیتا ہے۔ w، نیز کچھ اضافی آدانوں کو عام طور پر "غیر متعین مشورہ" کہا جاتا ہے اور چلتا ہے۔ ψ on w. مشورے کے آدانوں کو مدد کے لیے استعمال کیا جاتا ہے۔ C چلانے ψ، رکھنے کے دوران C چھوٹا مثال کے طور پر، ہر بار ψ دو نمبروں کو تقسیم کرتا ہے۔ x اور y, حصہ q اور باقی r کو مشورہ کے طور پر فراہم کیا جا سکتا ہے۔ C، اور C بس اسے چیک کر سکتے ہیں x = qy + r. یہ چیک بنانے سے کم مہنگا ہے۔ C حساب کرنے کے لیے ایک ڈویژن الگورتھم چلائیں۔ q اور r شروع سے.

آخر میں، سرکٹ کی اطمینان کے لیے ایک SNARK لاگو کیا جاتا ہے۔ C. اسے کہا جاتا ہے SNARK پسدید. مٹھی بھر انتہائی ساختی مسائل کے لیے جیسے میٹرکس ضرب, convolutions، اور گراف کے کئی مسائل، معروف SNARKs موجود ہیں جو اس فرنٹ اینڈ/بیک اینڈ کی تمثیل سے گریز کرتے ہیں اور اس طرح ایک بہت تیزی سے پرور حاصل کرتے ہیں۔ لیکن اس پوسٹ کا فوکس عام مقصد کے SNARKs پر ہے۔

جیسا کہ ہم دیکھیں گے، SNARK پسدید کی قیمتیں بڑھ رہی ہیں۔ Cکی سائز رکھنا C چھوٹا مشکل ہوسکتا ہے، کیونکہ سرکٹس ایک انتہائی محدود شکل ہے جس میں حساب کا اظہار کرنا ہے۔ ان پر مشتمل ہے۔ دروازے کی طرف سے منسلک تاروں. ہر ایک گیٹ g کچھ اقدار کو کھلایا جاتا ہے اور لاگو ہوتا ہے a بہت ان اقدار کے لیے سادہ فنکشن۔ اس کے بعد نتیجہ نکلنے والی تاروں کے ذریعے "ڈاؤن اسٹریم" گیٹس میں کھلایا جاتا ہے۔ g.

SNARK اسکیل ایبلٹی: اس میں واقعی کتنا وقت لگتا ہے؟

اہم سوال یہ ہے کہ، SNARK پروور کو مزید کتنا وقت لگتا ہے، محض دوبارہ عمل کرنے کے مقابلے میں ψ ڈیٹا پر؟ جواب ہے prover overhead SNARK کا، رشتہ دار براہ راست گواہوں کی جانچ. مؤخر الذکر اظہار اس حقیقت کی طرف اشارہ کرتا ہے کہ، جس میں بولی ثبوت میں P بھیجتا ہے w کرنے کے لئے V, V چیکس wکی توثیق عمل میں لا کر ψ اس پر. 

پروور اوور ہیڈ کو "فرنٹ اینڈ اوور ہیڈ" اور "بیک اینڈ اوور ہیڈ" میں توڑنا مفید ہے۔ اگر سرکٹ کا جائزہ لیا جائے۔ C گیٹ بہ گیٹ ہے F چلانے سے کئی گنا زیادہ مہنگا ψ، پھر ہم کہتے ہیں کہ فرنٹ اینڈ اوور ہیڈ ہے۔ F. اگر بیک اینڈ پروور کو لاگو کر رہے ہیں۔ C is B تشخیص سے کئی گنا زیادہ مہنگا C gate-by-gate، پھر ہم کہتے ہیں کہ بیک اینڈ اوور ہیڈ ہے۔ B. کل پروور اوور ہیڈ ہے۔ مصنوعات، F·B. یہ ضرب اوور ہیڈ کافی ہو سکتا ہے یہاں تک کہ اگر F اور B انفرادی طور پر معمولی ہیں۔ 

پریکٹس میں، F اور B دونوں تقریباً 1000 یا اس سے بڑے ہو سکتے ہیں۔ اس کا مطلب ہے کہ براہ راست گواہوں کی جانچ کے سلسلے میں کل پروور اوور ہیڈ 1 ملین سے 10 ملین یا اس سے زیادہ ہو سکتا ہے۔ ایک پروگرام جو لیپ ٹاپ پر صرف ایک سیکنڈ تک چلتا ہے آسانی سے SNARK پروور کی طرف لے جا سکتا ہے جس کے لیے دسیوں یا سیکڑوں دن کا حساب وقت درکار ہوتا ہے (سنگل تھریڈڈ)۔ خوش قسمتی سے، یہ کام عام طور پر مختلف حدوں کے متوازی ہوتا ہے (SNARK پر منحصر ہے)۔ 

خلاصہ یہ کہ، اگر آپ آج کسی ایپلیکیشن میں SNARK استعمال کرنا چاہتے ہیں، تو تین چیزوں میں سے ایک درست ہونا ضروری ہے:

1. لیپ ٹاپ پر براہ راست گواہ کی جانچ میں ایک سیکنڈ سے بھی کم وقت لگتا ہے۔
2. براہ راست گواہ کی جانچ سرکٹ میں نمائندگی کے لیے خاص طور پر قابل عمل ہے، اس لیے فرنٹ اینڈ اوور ہیڈ چھوٹا ہے۔
3. آپ SNARK prover کے ختم ہونے کے لیے دن انتظار کرنے کے لیے تیار ہیں، اور/یا بھاری متوازی کمپیوٹ وسائل کی ادائیگی کے لیے تیار ہیں۔

Tوہ اس پوسٹ کا باقی حصہ بتاتا ہے کہ فرنٹ اینڈ اور بیک اینڈ اوور ہیڈ کہاں سے آتے ہیں، اور میں مختلف SNARKs کے لیے ان کا اندازہ کیسے لگاتا ہوں۔ پھر ہم بہتری کے امکانات کی طرف رجوع کریں گے۔ 

فرنٹ اینڈ اور بیک اینڈ کو الگ کرنا

بیک اینڈ سے فرنٹ اینڈ کو مکمل طور پر الگ کرنا مشکل ہوسکتا ہے کیونکہ مختلف بیک اینڈ مختلف قسم کے سرکٹس کو سپورٹ کرتے ہیں۔ لہذا، فرنٹ اینڈز پسدید کے لحاظ سے مختلف ہوسکتے ہیں جس کے ساتھ وہ انٹرفیس کی توقع کرتے ہیں۔

SNARK بیک اینڈز عام طور پر نام نہاد ریاضی کے سرکٹس کی حمایت کرتے ہیں، مطلب یہ ہے کہ سرکٹس کے اندراج کچھ محدود فیلڈ کے عناصر ہیں، اور یہ کہ سرکٹ کے دروازے دو فیلڈ عناصر کا اضافہ اور ضرب انجام دیتے ہیں۔ یہ سرکٹس تقریباً سیدھے لکیر والے کمپیوٹر پروگراموں سے مطابقت رکھتے ہیں (کوئی شاخیں نہیں، مشروط بیانات وغیرہ) جو کہ الجبرائی نوعیت کے ہوتے ہیں — یعنی ان کی ابتدائی ڈیٹا کی قسم فیلڈ عناصر ہیں۔ 

زیادہ تر بیک اینڈز دراصل ریاضی کے سرکٹس کے عام ہونے کی حمایت کرتے ہیں جنہیں اکثر Rank-1 Constraint Satisfaction (R1CS) مثال کہا جاتا ہے۔ کی قابل ذکر رعایت کے ساتھ گروتھ 16 اور اس کے پیشرو، ان SNARKs کو دوسرے IRs کو بھی سپورٹ کرنے کے لیے بنایا جا سکتا ہے۔ مثال کے طور پر، StarkWare الجبریک انٹرمیڈیٹ ریپریزنٹیشن (AIR) نامی کوئی چیز استعمال کرتا ہے، جو کہ ایک تصور کی طرح بھی ہے۔ PlonKish ریاضی جسے PlonK اور دیگر بیک اینڈز سے سپورٹ کیا جا سکتا ہے۔ زیادہ عام IRs کو سپورٹ کرنے کے لیے کچھ بیک اینڈز کی صلاحیت فرنٹ اینڈز کے اوور ہیڈ کو کم کر سکتی ہے جو ان IRs کو تیار کرتے ہیں۔ 

بیک اینڈ ان محدود فیلڈز کے لحاظ سے بھی مختلف ہوتے ہیں جن کی وہ مقامی طور پر حمایت کرتے ہیں۔ میں اگلے حصے میں اس پر مزید بات کروں گا۔

فرنٹ اینڈ پر مختلف نقطہ نظر

کچھ (بہت خاص) کمپیوٹر پروگرام قدرتی طور پر ریاضی کے سرکٹس سے مطابقت رکھتے ہیں۔ اس کی ایک مثال کمپیوٹر پروگرام ہے جو کسی فیلڈ پر میٹرکس کی سادہ ضرب کاری کرتا ہے۔ لیکن زیادہ تر کمپیوٹر پروگرام نہ تو سیدھی لائن ہیں اور نہ ہی الجبری۔ ان میں اکثر مشروط بیانات، انٹیجر ڈویژن یا فلوٹنگ پوائنٹ ریاضی جیسے آپریشنز شامل ہوتے ہیں جو فطری طور پر محدود فیلڈ ریاضی سے مطابقت نہیں رکھتے، اور بہت کچھ۔ ان صورتوں میں، فرنٹ اینڈ اوور ہیڈ کافی ہوگا۔ 

ایک مقبول فرنٹ اینڈ نقطہ نظر سرکٹس تیار کرنا ہے جو بنیادی طور پر مرحلہ وار کچھ سادہ سی پی یو کو چلاتے ہیں، جسے ورچوئل مشین (VM) بھی کہا جاتا ہے۔ فرنٹ اینڈ ڈیزائنرز اصلی کمپیوٹر پروسیسرز کے لیے اسمبلی ہدایات کے مشابہ "پرائمیٹو آپریشنز" کا ایک سیٹ بتاتے ہیں۔ وہ ڈویلپر جو فرنٹ اینڈ کو استعمال کرنا چاہتے ہیں وہ یا تو براہ راست اسمبلی کی زبان میں "گواہوں کی جانچ پڑتال کے پروگرام" لکھیں گے یا پھر کچھ اعلی سطحی زبان جیسے سالیڈٹی میں، اور ان کے پروگرام خود بخود اسمبلی کوڈ میں مرتب ہوں گے۔ 

مثال کے طور پر، StarkWare's قاہرہ ایک بہت ہی محدود اسمبلی لینگویج ہے جس میں اسمبلی ہدایات تقریباً ایک محدود فیلڈ، فنکشن کالز، اور ایک ناقابل تغیر (یعنی ایک بار لکھنے والی) میموری کو پڑھنے اور لکھنے میں اضافے اور ضرب کی اجازت دیتی ہیں۔ قاہرہ VM ایک وان نیومن فن تعمیر ہے، مطلب یہ ہے کہ فرنٹ اینڈ کے ذریعہ تیار کردہ سرکٹس بنیادی طور پر قاہرہ پروگرام کو عوامی ان پٹ کے طور پر لیتے ہیں اور گواہ پر پروگرام کو "چلاتے" ہیں۔ قاہرہ کی زبان ٹورنگ مکمل ہے — اس کے محدود ہدایات کے سیٹ کے باوجود، یہ زیادہ معیاری فن تعمیرات کی نقالی کر سکتی ہے، حالانکہ ایسا کرنا مہنگا پڑ سکتا ہے۔ قاہرہ کے فرنٹ اینڈ نے قاہرہ کے پروگراموں کو عمل میں لایا ہے۔ T ابتدائی ہدایات جس کو "ڈگری" کہا جاتا ہے2 AIR کے ساتھ T قطاریں اور اس کے بارے میں 50 کالم۔" کیا بالکل اس کا مطلب ہے اس پوسٹ کے لیے اہم نہیں ہے، لیکن جہاں تک SNARK provers کا تعلق ہے، یہ ہر ایک کے لیے 50 اور 100 کے درمیان گیٹس والے سرکٹس کے مساوی ہے۔ T قاہرہ سی پی یو کے مراحل۔ 

RISC زیرو قاہرہ کے لیے بھی ایسا ہی طریقہ اختیار کرتا ہے، لیکن ورچوئل مشین کے نام نہاد ہونے کے ساتھ RISC-V فن تعمیر، ایک بھرپور سافٹ ویئر ایکو سسٹم کے ساتھ ایک اوپن سورس فن تعمیر جو مقبولیت میں بڑھ رہا ہے۔ ایک بہت ہی آسان انسٹرکشن سیٹ کے طور پر، ایک موثر SNARK فرنٹ اینڈ ڈیزائن کرنا جو اس کی حمایت کرتا ہے نسبتاً قابل عمل ہو سکتا ہے (کم از کم پیچیدہ فن تعمیر جیسے x86 یا ARM سے نسبت)۔ مئی تک، RISC زیرو پروگرام بدل رہا ہے پھانسی T ابتدائی RISC-V ہدایات ڈگری-5 AIRs کے ساتھ 3T قطاریں اور 160 کالم یہ کم از کم کے ساتھ سرکٹس کے مساوی ہے 500 RISC-V CPU کے فی قدم دروازے۔ مستقبل قریب میں مزید بہتری متوقع ہے۔

مختلف zkEVM پروجیکٹس (مثال کے طور پر، zkSync 2.0، Scroll، Polygon's zkEVM) ورچوئل مشین کو (duh) Ethereum ورچوئل مشین مانتے ہیں۔ ہر EVM ہدایات کو مساوی "گیجٹ" میں تبدیل کرنے کا عمل (یعنی، ہدایات کو نافذ کرنے والا ایک بہتر سرکٹ) آسان قاہرہ اور RISC-V فن تعمیر کے مقابلے میں کافی زیادہ شامل ہے۔ اس اور دیگر وجوہات کی بناء پر, کچھ zkEVM پروجیکٹس ای وی ایم انسٹرکشن سیٹ کو براہ راست لاگو نہیں کر رہے ہیں بلکہ سرکٹس میں تبدیل کرنے سے پہلے اعلی سطحی سولیڈیٹی پروگراموں کو دیگر اسمبلی زبانوں میں مرتب کر رہے ہیں۔ ان منصوبوں کی کارکردگی کے نتائج زیر التوا ہیں۔

"CPU ایمولیٹر" پروجیکٹس جیسے RISC-V اور قاہرہ ایک واحد سرکٹ تیار کرتے ہیں جو متعلقہ اسمبلی کی زبان میں تمام پروگراموں کو سنبھال سکتا ہے۔ متبادل نقطہ نظر "ASIC جیسے" ہیں، جو مختلف پروگراموں کے لیے مختلف سرکٹس تیار کرتے ہیں۔ یہ ASIC جیسا نقطہ نظر کچھ پروگراموں کے لیے چھوٹے سرکٹس پیدا کر سکتا ہے، خاص طور پر جب اسمبلی کی ہدایات جو پروگرام ہر ٹائم سٹیپ پر عمل کرتا ہے اس کا انحصار پروگرام کے ان پٹ پر نہیں ہوتا ہے۔ مثال کے طور پر، یہ براہ راست لائن پروگراموں جیسے کہ naive matrix multiplication کے لیے ممکنہ طور پر فرنٹ اینڈ اوور ہیڈ سے بچ سکتا ہے۔ لیکن ASIC نقطہ نظر بھی انتہائی محدود لگتا ہے۔ جہاں تک میں جانتا ہوں، یہ معلوم نہیں ہے کہ اسے پہلے سے طے شدہ تکرار کی حدوں کے بغیر لوپس کو سپورٹ کرنے کے لیے کیسے استعمال کیا جائے۔ 

فرنٹ اینڈ اوور ہیڈ کا حتمی جزو اس حقیقت سے آتا ہے کہ تمام SNARK سرکٹس استعمال کرتے ہیں جو محدود فیلڈز پر کام کرتے ہیں۔ آپ کے لیپ ٹاپ پر موجود CPU ایک مشین کی ہدایات کے ساتھ دو عدد عدد کو ضرب یا جوڑ سکتا ہے۔ اگر فرنٹ اینڈ کافی بڑی خصوصیت والے فیلڈ پر ایک سرکٹ کو آؤٹ پٹ کرتا ہے، تو یہ متعلقہ فیلڈ آپریشن کے ذریعے اس ضرب یا اضافے کو لازمی طور پر نقل کر سکتا ہے۔ تاہم، ایک حقیقی سی پی یو پر فیلڈ آپریشن کو لاگو کرنے کے لیے عام طور پر مشین کی بہت سی ہدایات درکار ہوں گی (حالانکہ کچھ جدید پروسیسرز کو مخصوص فیلڈز کے لیے مقامی حمایت حاصل ہے)۔ 

کچھ SNARK بیک اینڈز دوسروں کے مقابلے زیادہ لچکدار فیلڈ انتخاب کو اہل بناتے ہیں۔ مثال کے طور پر، اگر بیک اینڈ ایک کرپٹوگرافک گروپ کا استعمال کرتا ہے۔ G، سرکٹ کے فیلڈ کو عناصر کی تعداد سے مماثل ہونا چاہئے۔ G، جو محدود ہو سکتا ہے۔ اس کے علاوہ، تمام فیلڈز عملی FFT الگورتھم کی حمایت نہیں کرتے ہیں۔ 

صرف ایک نافذ SNARK ہے، گرا، جو مقامی طور پر صوابدیدی (کافی بڑے) فیلڈز پر حسابات کی حمایت کرتا ہے۔ اس کے ساتھ ساتھ اولاد، اس کی سب سے تیز ترین کنکریٹ پروور کارکردگی ہے یہاں تک کہ ان فیلڈز پر بھی جن کی دیگر SNARK حمایت کرتے ہیں، لیکن اس کے ثبوت فی الحال بہت سی بلاکچین ایپلی کیشنز کے لیے بہت زیادہ ہیں۔ حالیہ کام ثبوت کے سائز کو بہتر بنانے کی کوشش کرتا ہے، لیکن کہاوت غیر علامتی طور پر سست اور وہیں ہے۔ معلوم ہوتا ہے جیسے راہ میں حائل رکاوٹیں عملی طور پر

کچھ پروجیکٹس نے خاص طور پر تیز ریاضی کے ساتھ فیلڈز پر کام کرنے کا انتخاب کیا ہے۔ مثال کے طور پر، Plonky2 اور دیگر خصوصیت 2 کا فیلڈ استعمال کرتے ہیں۔⁶⁴ - 2³² + 1 کیونکہ اس فیلڈ میں ریاضی کو کم ساخت والے فیلڈز کے مقابلے میں کئی گنا زیادہ تیزی سے لاگو کیا جا سکتا ہے۔ تاہم، اس طرح کی ایک چھوٹی خصوصیت کا استعمال فیلڈ آپریشنز کے ذریعے عددی ریاضی کی مؤثر طریقے سے نمائندگی کرنے میں چیلنجوں کا باعث بن سکتا ہے (مثال کے طور پر، دو 32 بٹ غیر دستخط شدہ عدد کو ضرب دینے سے فیلڈ کی خصوصیت سے زیادہ نتیجہ نکل سکتا ہے)۔ 

 لیکن اس سے کوئی فرق نہیں پڑتا ہے کہ آج تمام مشہور SNARKs کے لیے 128 بٹس سیکیورٹی حاصل کرنے کے لیے (تصدیق کے اخراجات میں نمایاں اضافہ کیے بغیر)، انہیں 2 سے بڑے سائز کے فیلڈ پر کام کرنا ہوگا۔¹²⁸. جہاں تک میں بتا سکتا ہوں، اس کا مطلب ہے کہ ہر فیلڈ آپریشن کے لیے کم از کم دس 64 بٹ مشین ضرب، اور کافی زیادہ اضافے اور بٹ وائز آپریشنز کی ضرورت ہوگی۔ لہٰذا، محدود فیلڈز پر کام کرنے والے سرکٹس کی ضرورت کی وجہ سے کسی کو کم از کم فرنٹ اینڈ اوور ہیڈ کے طول و عرض کے ایک آرڈر میں فیکٹر کرنا چاہیے۔ 

خلاصہ کرنے کے لیے، موجودہ فرنٹ اینڈز جو ورچوئل مشین تجرید کا استعمال کرتے ہیں وہ ورچوئل مشین کے فی قدم 100x سے 1000x گیٹس کے ساتھ سرکٹس تیار کرتے ہیں، اور ممکنہ طور پر زیادہ پیچیدہ ورچوئل مشینوں کے لیے زیادہ۔ اس کے اوپری حصے میں، محدود فیلڈ ریاضی جدید پروسیسرز پر مشابہ ہدایات سے کم از کم 10x سست ہے (ممکنہ استثناء کے ساتھ اگر پروسیسر کے پاس کچھ فیلڈز کے لیے بلٹ ان سپورٹ ہے)۔ ایک "ASIC فرنٹ اینڈ اپروچ" ان میں سے کچھ اوور ہیڈز کو کم کر سکتا ہے لیکن فی الحال اس قسم کے پروگراموں میں محدود ہے جن کی یہ حمایت کر سکتی ہے۔

پسدید کی رکاوٹیں کیا ہیں؟

سرکٹ کی اطمینان کے لیے SNARKs کو عام طور پر ایک معلوماتی نظریاتی طور پر محفوظ پروٹوکول کو ملا کر ڈیزائن کیا جاتا ہے جسے "کثیر الثانی IOP"کرپٹوگرافک پروٹوکول کے ساتھ"کثیر الثانی عزم اسکیم" زیادہ تر معاملات میں، پروور کے لیے ٹھوس رکاوٹ کثیر الثانی کمٹمنٹ اسکیم ہے۔ خاص طور پر، ان SNARKs میں ایک یا ایک سے زیادہ کثیر الثانیات جن کی ڈگری ہے (کم از کم) |C|، سرکٹ میں دروازوں کی تعداد C. 

بدلے میں، کثیر الثانی کمٹمنٹ اسکیم کے اندر کنکریٹ کی رکاوٹ کا انحصار استعمال شدہ اسکیم اور سرکٹ کے سائز پر ہوگا۔ لیکن یہ ہمیشہ مندرجہ ذیل تین آپریشنز میں سے ایک ہو گا: کمپیوٹنگ FFTs، ایک کرپٹوگرافک گروپ میں ایکسپونیشن، یا مرکل ہیشنگ. مرکل ہیشنگ عام طور پر صرف اس صورت میں ایک رکاوٹ ہے جب سرکٹ چھوٹا ہو، لہذا ہم اس پر مزید بات نہیں کریں گے۔ 

مجرد لاگ پر مبنی کثیر الثانی وعدے

ایک کرپٹوگرافک گروپ میں مجرد لوگارتھم کے مسئلے کی سختی پر مبنی متعدد وعدوں میں G (KZG, بلٹ پروف, ڈوری، اور Hyrax-commit) کہنے والے کو حساب لگانا پڑتا ہے۔ Pedersen ویکٹر عزم کثیر الجہتی کے گتانک تک۔ اس میں کثیر الاضلاع شامل ہے، جس کا سائز کثیر الثانی کی ڈگری کے برابر ہے۔ SNARKs میں، یہ ڈگری عام طور پر سائز کی ہوتی ہے۔ |C| سرکٹ کی C.

آسانی سے کیا گیا، سائز کا ایک کثیر الاضلاع |C| تقریباً 1.5 درکار ہیں۔·|C|·لاگ ان کریں |G| ≈ 400·|C| گروپ آپریشنز، کہاں |G| گروپ میں عناصر کی تعداد کو ظاہر کرتا ہے۔ G. تاہم، ایک نقطہ نظر ہے، جسے Pippenger's algorithm کہا جاتا ہے، جو اسے تقریباً لاگ کے عنصر سے کم کر سکتا ہے۔ |C|. بڑے سرکٹس کے لیے (کہتے ہیں، |C| ≥ 225)، یہ لاگ |C| فیکٹر کنکریٹ طور پر 25 یا اس سے زیادہ ہو سکتا ہے، یعنی بڑے سرکٹس کے لیے، ہم توقع کرتے ہیں کہ پیڈرسن ویکٹر کی کمٹمنٹ 10 سے کچھ زیادہ کے ساتھ کمپیوٹیبل ہو سکتی ہے۔·|C| گروپ آپریشنز. بدلے میں ہر گروپ کا آپریشن ایک محدود فیلڈ آپریشن سے تقریباً 10x سست ہوتا ہے (ایک انتہائی کھردری بالپارک کے طور پر)۔ ان کثیر الثانی وعدوں کو استعمال کرنے والے SNARK اتنے ہی مہنگے ہیں۔ P تقریبا 100 کے طور پر·|C| فیلڈ آپریشنز 

بدقسمتی سے، موجودہ SNARKs کے اوپر 100x فیکٹر کے اوپر اضافی اوور ہیڈز ہیں۔ مثال کے طور پر:

• Spartan's prover، جو Hyrax polynomial عزم کا استعمال کرتا ہے، کرنا پڑتا ہے۔ |C|^½ سائز میں سے ہر ایک کے بہت سے ملٹی ایکسپوینشنز |C|^½تقریباً دو کے فیکٹر سے Pippenger کے الگورتھم سے اسپیڈ اپ کو کمزور کرنا۔ 
• In گروتھ 16, P جوڑا بنانے کے لیے دوستانہ گروپ پر کام کرنا چاہیے، جس کے آپریشنز عام طور پر ان گروپوں کے مقابلے میں کم از کم 2x سست ہوتے ہیں جو جوڑا بنانے کے لیے دوستانہ نہیں ہیں۔ P 3 کے بجائے 1 ملٹی ایکسپوینشنز بھی انجام دینے چاہئیں۔ مشترکہ طور پر، اس کے نتیجے میں 6 کے مقابلے میں کم از کم ایک اضافی عنصر-100 سست ہو جاتا ہے۔·|C| اوپر کا تخمینہ 
• مارلن اور PlonK جوڑے بنانے کی بھی ضرورت ہوتی ہے، اور ان کے پروررز کو کافی حد تک 3 سے زیادہ کثیر الثانیات کا عہد کرنا ہوتا ہے۔ 
• کسی بھی SNARK کے لیے جو استعمال کرتا ہے۔ بلٹ پروف (مثال کے طور پر، ہیلو 2جو کہ تقریباً PlonK ہے لیکن KZG کثیر الثقافتی وعدوں کے بجائے بلٹ پروف کے ساتھ)، پروور کو کمٹمنٹ اسکیم کے "افتتاحی" مرحلے کے دوران لاگریتھمک طور پر بہت سے ملٹی ایکسپوینشنز کی گنتی کرنی پڑتی ہے، اور یہ بڑی حد تک کسی بھی Pippenger کی رفتار کو مٹا دیتا ہے۔ 

خلاصہ طور پر، پیڈرسن ویکٹر کمٹمنٹس استعمال کرنے والے معلوم SNARK میں کم از کم 200x اور 1000x یا اس سے زیادہ کا بیک اینڈ اوور ہیڈ ہوتا ہے۔ 

دیگر کثیر الثانی وعدے

SNARKs کے لیے دیگر متعدد وعدوں کا استعمال کرتے ہوئے (جیسے FREE اور Ligero- عزم)، رکاوٹ یہ ہے کہ پروور کو بڑے ایف ایف ٹی انجام دینے کی ضرورت ہے۔ مثال کے طور پر، قاہرہ کی طرف سے تیار کردہ ڈگری-2 AIRs میں (51 کالموں کے ساتھ اور T قطاریں، قاہرہ سی پی یو کا ایک فی قدم)، سٹارک ویئر کا تعینات پروور کم از کم 2 ایف ایف ٹی فی کالم کرتا ہے، جس کی لمبائی کے درمیان 16T اور 32T. مستقل 16 اور 32 FRI کے اندرونی پیرامیٹرز پر انحصار کرتا ہے جیسا کہ StarkWare کے ذریعہ ترتیب دیا گیا ہے اور اسے کم کیا جا سکتا ہے — لیکن تصدیق کے بڑھتے ہوئے اخراجات کی قیمت پر۔ 

امید کے مطابق، لمبائی 32 کا ایک ایف ایف ٹی·T تقریبا 64 لیتا ہے·T·لاگ (32T) فیلڈ ضرب۔ اس کا مطلب یہ ہے کہ نسبتاً چھوٹی اقدار کے لیے بھی T (مثال کے طور پر، T ≥ 2²⁰فی کالم فیلڈ آپریشنز کی تعداد کم از کم 64 ہے۔·25·T1600 =·T. تو پسدید اوور ہیڈ کم از کم ہزاروں میں دکھائی دیتا ہے۔ مزید برآں، یہ بھی ممکن ہے کہ فیلڈ آپریشنز کے مقابلے میں بڑی FFTs میموری بینڈوڈتھ کے ذریعے زیادہ رکاوٹ کا شکار ہوں۔ 

کچھ سیاق و سباق میں، SNARKs کے بیک اینڈ اوور ہیڈ جو بڑے FFTs کو انجام دیتے ہیں کو پروف ایگریگیشن نامی تکنیک سے کم کیا جا سکتا ہے۔ رول اپ کے لیے، اس کا مطلب یہ ہوگا۔ P (رول اپ سروس) لین دین کے ایک بڑے بیچ کو 10 چھوٹے بیچوں میں توڑ دیتی ہے۔ ہر چھوٹے بیچ کے لیے i, P ایک SNARK ثبوت تیار کرتا ہے۔ πi بیچ کی درستگی کا۔ لیکن P ان ثبوتوں کو Ethereum پر پوسٹ نہیں کرتا، کیونکہ اس سے گیس کی قیمتوں میں تقریباً 10 گنا اضافہ ہوگا۔ اس کے بجائے، SNARK کو دوبارہ لاگو کیا گیا ہے، اس بار ثبوت پیش کرنے کے لیے π اس کو قائم کرنا P جانتا ہے π₁ ،…،π₁₀. یعنی گواہ وہ P جاننے کا دعویٰ دس ثبوت π ہے۔₁،…،π₁₀، اور براہ راست گواہ کی جانچ SNARK تصدیقی طریقہ کار کو ہر ایک ثبوت پر لاگو کرتی ہے۔ یہ واحد ثبوت π Ethereum پر پوسٹ کیا گیا ہے۔ 

FRI اور Ligero-commit جیسے متعدد وعدوں میں، کے درمیان ایک مضبوط تناؤ ہے۔ P وقت اور V لاگت، داخلی پیرامیٹرز کے ساتھ ایک نوب کے طور پر کام کرتے ہیں جو ایک دوسرے کے لیے تجارت کر سکتے ہیں۔ چونکہ π₁ ،…،π₁₀ Ethereum پر پوسٹ نہیں کر رہے ہیں، نوب کو ٹیون کیا جا سکتا ہے تو یہ ثبوت بڑے ہیں، اور ان کی پیداوار تیز تر ہے۔ صرف SNARK کے حتمی اطلاق میں، مجموعی طور پر π₁ ،…،π₁₀ ایک ثبوت میں π, کیا کمٹمنٹ اسکیم کو چھوٹے ثبوت کو یقینی بنانے کے لیے ترتیب دینے کی ضرورت ہے۔ 

StarkWare ثبوت جمع کرنے کا ارادہ رکھتا ہے۔ فوری طور پر. یہ بھی جیسے منصوبوں کی توجہ کا مرکز ہے۔ Plonky2.

SNARK اسکیل ایبلٹی میں دیگر رکاوٹیں کیا ہیں؟

اس پوسٹ نے پرور پر توجہ مرکوز کی ہے۔ وقت، لیکن دیگر پروور اخراجات بھی توسیع پذیری کی رکاوٹیں ہو سکتی ہیں۔ مثال کے طور پر، بہت سے SNARK بیک اینڈز کے لیے پروور کو ہر گیٹ کے لیے کئی فیلڈ عناصر کو ذخیرہ کرنے کی ضرورت ہوتی ہے۔ C، اور اس جگہ کی قیمت بہت زیادہ ہوسکتی ہے۔ مثال کے طور پر ایک پروگرام ψ ایک لیپ ٹاپ پر ایک سیکنڈ میں چلنا ایک جدید پروسیسر پر شاید ایک ارب قدیم آپریشنز انجام دے سکتا ہے۔ جیسا کہ ہم نے دیکھا ہے، عام طور پر کسی کو توقع کرنی چاہیے۔ C اس طرح کے آپریشن کے لیے 100 سے زیادہ گیٹس کی ضرورت ہوتی ہے۔ اس کا مطلب ہے 100 بلین گیٹس، جو SNARK پر منحصر ہے، اس کا مطلب ہو سکتا ہے دسیوں یا سینکڑوں ٹیرا بائٹس کی جگہ P. 

ایک اور مثال: بہت سے مشہور SNARKs (مثال کے طور پر، PlonK, مارلن, گروتھ 16) کو ایک پیچیدہ "قابل اعتماد سیٹ اپ تقریب" کی ضرورت ہوتی ہے تاکہ ایک منظم "ثابت کنجی" تیار کی جا سکے۔ جسے پرور کے ذریعہ ذخیرہ کیا جانا چاہئے۔ جہاں تک میں جانتا ہوں، the ایسی سب سے بڑی تقریب تقریباً 2 کے ساتھ سرکٹس کو سپورٹ کرنے کے قابل ثابت کرنے والی کلید تیار کی۔²⁸≈250 ملین گیٹس۔ ثابت کرنے والی کلید کا سائز کئی درجن گیگا بائٹس ہے۔ 

سیاق و سباق میں جہاں ثبوت جمع کرنا ممکن ہے، ان رکاوٹوں کو کافی حد تک کم کیا جا سکتا ہے۔ 

آگے دیکھ رہے ہیں: مزید توسیع پذیر SNARKs کے امکانات

دونوں فرنٹ اینڈ اور بیک اینڈ اوور ہیڈز تین آرڈرز یا اس سے زیادہ ہو سکتے ہیں۔ کیا ہم مستقبل قریب میں ان میں خاطر خواہ کمی کی توقع کر سکتے ہیں؟ 

مجھے لگتا ہے کہ ہم کریں گے - ایک نقطہ تک۔ سب سے پہلے، آج کے تیز ترین بیک اینڈز (مثلاً، Spartan اور گرا، اور دیگر SNARK جو یکجا کرتے ہیں۔ sum-check پروٹوکول کثیر الثانی وعدوں کے ساتھ) کے پاس بڑے ثبوت ہیں - عام طور پر سرکٹ کے سائز میں مربع جڑ - لہذا لوگ واقعی ان کا استعمال نہیں کر رہے ہیں۔ میں توقع کرتا ہوں کہ مستقبل قریب میں چھوٹے پروف SNARKs کے ساتھ ڈیپتھ ون کمپوزیشن کے ذریعے پروف سائز اور تصدیق کرنے کا وقت بامعنی طور پر کم ہو جائے گا۔ ثبوت جمع کرنے کی طرح، اس کا مطلب ہے کہ پروور پہلے SNARK ثبوت تیار کرے گا π "تیز ثابت کرنے والے، بڑے پروف" SNARK کے ساتھ، لیکن بھیجے نہیں۔ π کرنے کے لئے V. بلکہ، P ثبوت پیش کرنے کے لیے چھوٹے پروف SNARK کا استعمال کرے گا۔ π' کہ یہ جانتا ہے π, اور بھیجیں π' کرنے کے لئے V. اس سے SNARKs کے بیک اینڈ اوور ہیڈز کی شدت کا حکم منڈوا سکتا ہے جو آج مقبول ہیں۔ 

دوسرا، ہارڈویئر ایکسلریشن میں مدد مل سکتی ہے۔ ایک بہت ہی عام اصول یہ ہے کہ GPUs CPUs پر 10x اسپیڈ اپ خرید سکتے ہیں، اور ASICs GPUs پر 10x اسپیڈ اپ خرید سکتے ہیں۔ تاہم، مجھے اس محاذ پر تین خدشات ہیں۔ سب سے پہلے، بڑے FFTs کو فیلڈ آپریشنز کے بجائے میموری بینڈوڈتھ کی وجہ سے رکاوٹ کا سامنا کرنا پڑ سکتا ہے، لہذا SNARKs جو اس طرح کے FFTs کو انجام دیتے ہیں وہ خصوصی ہارڈ ویئر سے محدود رفتار دیکھ سکتے ہیں۔ دوسرا، جب کہ اس پوسٹ نے کثیر الجہتی عزم کی رکاوٹ پر توجہ مرکوز کی ہے، بہت سے SNARKs کو پروور سے دوسرے آپریشن کرنے کی ضرورت ہوتی ہے جو صرف قدرے کم مہنگے ہوتے ہیں۔ لہذا کثیر الثانی عزم کی رکاوٹ کو توڑنا (مثال کے طور پر، ملٹی ایکسپوینشنز کو تیز کرنا discrete-log-based SNARKs میں) ایک نیا رکاوٹ آپریشن چھوڑ سکتا ہے جو پرانے سے بہت بہتر نہیں ہے۔ (مثال کے طور پر، SNARKs بشمول Groth16، Marlin، اور PlonK میں کثیر الاضلاع کے علاوہ FFTs بھی کہا جاتا ہے۔) آخر میں، فیلڈز اور بیضوی منحنی خطوط جو سب سے زیادہ کارآمد SNARKs کی طرف لے جاتے ہیں کچھ وقت کے لیے تیار ہوتے رہ سکتے ہیں، اور یہ ASIC پر مبنی پروور ایکسلریشن کے لیے چیلنجز پیدا کر سکتے ہیں۔

فرنٹ اینڈ سائیڈ پر، ہم تیزی سے یہ محسوس کر سکتے ہیں کہ قاہرہ، RISC زیرو، zkEVMs، اور دیگر جیسے پروجیکٹس کا "CPU ایمولیٹر" نقطہ نظر دراصل CPU انسٹرکشن سیٹس کی پیچیدگی کے ساتھ (کارکردگی کے لحاظ سے) کافی اچھا ہے۔ درحقیقت، یہ بالکل مختلف zkEVM پروجیکٹوں کی امید ہے۔ اس کا مطلب یہ ہو سکتا ہے کہ، جب کہ فرنٹ اینڈ اوور ہیڈ کی شدت کے تین آرڈرز یا اس سے زیادہ رہتے ہیں، فرنٹ اینڈ ایسے VMs کو سپورٹ کرنے کا انتظام کرتے ہیں جو حقیقی CPU فن تعمیر سے تیزی سے میل کھاتے ہیں۔ ایک جوابی تشویش یہ ہے کہ فرنٹ اینڈ پیچیدہ ہو سکتے ہیں اور آڈٹ کرنا مشکل ہو سکتا ہے، کیونکہ ہینڈ کوڈ والے گیجٹس تیزی سے پیچیدہ ہدایات پر عمل درآمد کر رہے ہیں۔ تصدیق کے رسمی طریقے ممکنہ طور پر اس تشویش کو دور کرنے میں اہم کردار ادا کریں گے۔ 

آخر میں، کم از کم بلاکچین ایپلی کیشنز میں، ہم یہ دیکھ سکتے ہیں کہ جنگل میں ظاہر ہونے والے زیادہ تر سمارٹ معاہدے بنیادی طور پر سادہ، SNARK کے موافق ہدایات کا استعمال کرتے ہیں۔ یہ عمومیت اور بہتر ڈویلپر کے تجربے کو برقرار رکھتے ہوئے عملی طور پر کم فرنٹ اینڈ اوور ہیڈز کو قابل بنا سکتا ہے جو کہ اعلی سطحی پروگرامنگ زبانوں جیسے سالیڈیٹی اور بھرپور انسٹرکشن سیٹس بشمول ای وی ایم کے ساتھ آتا ہے۔ 

***

جسٹن تھیلر is جارج ٹاؤن یونیورسٹی میں ایک ایسوسی ایٹ پروفیسر۔ جارج ٹاؤن میں شامل ہونے سے پہلے، اس نے نیویارک میں یاہو لیبز میں ریسرچ سائنٹسٹ کے طور پر دو سال گزارے، اس سے پہلے وہ اس میں ریسرچ فیلو تھے۔ سائمن انسٹی ٹیوٹ فار دی تھیوری آف کمپیوٹنگ یو سی برکلے میں۔ 

***

اعترافات: میں شکر گزار ہوں۔ ایلینا برگر اس پوسٹ کا موضوع تجویز کرنے کے لیے، اور ارسو ارون، جوزف بونیو، اور سیم راگسڈیل بصیرت انگیز تبصروں کے لیے۔ میرے ایڈیٹر کا بھی خصوصی شکریہ، ٹم سلیوان۔.

***

یہاں بیان کردہ خیالات انفرادی AH Capital Management, LLC ("a16z") کے اہلکاروں کے ہیں جن کا حوالہ دیا گیا ہے اور یہ a16z یا اس سے وابستہ افراد کے خیالات نہیں ہیں۔ یہاں پر موجود کچھ معلومات فریق ثالث کے ذرائع سے حاصل کی گئی ہیں، بشمول a16z کے زیر انتظام فنڈز کی پورٹ فولیو کمپنیوں سے۔ جب کہ معتبر مانے جانے والے ذرائع سے لیا گیا ہے، a16z نے آزادانہ طور پر ایسی معلومات کی تصدیق نہیں کی ہے اور معلومات کی پائیدار درستگی یا دی گئی صورت حال کے لیے اس کی مناسبیت کے بارے میں کوئی نمائندگی نہیں کی ہے۔ اس کے علاوہ، اس مواد میں فریق ثالث کے اشتہارات شامل ہو سکتے ہیں۔ a16z نے ایسے اشتہارات کا جائزہ نہیں لیا ہے اور اس میں موجود کسی بھی اشتہاری مواد کی توثیق نہیں کرتا ہے۔

یہ مواد صرف معلوماتی مقاصد کے لیے فراہم کیا گیا ہے، اور قانونی، کاروبار، سرمایہ کاری، یا ٹیکس کے مشورے کے طور پر اس پر انحصار نہیں کیا جانا چاہیے۔ آپ کو ان معاملات کے بارے میں اپنے مشیروں سے مشورہ کرنا چاہئے۔ کسی بھی سیکیورٹیز یا ڈیجیٹل اثاثوں کے حوالے صرف مثالی مقاصد کے لیے ہیں، اور سرمایہ کاری کی سفارش یا پیشکش کی تشکیل نہیں کرتے ہیں کہ سرمایہ کاری کی مشاورتی خدمات فراہم کریں۔ مزید برآں، یہ مواد کسی سرمایہ کار یا ممکنہ سرمایہ کاروں کی طرف سے استعمال کرنے کے لیے نہیں ہے اور نہ ہی اس کا مقصد ہے، اور کسی بھی صورت میں a16z کے زیر انتظام کسی بھی فنڈ میں سرمایہ کاری کرنے کا فیصلہ کرتے وقت اس پر انحصار نہیں کیا جا سکتا ہے۔ (a16z فنڈ میں سرمایہ کاری کرنے کی پیشکش صرف پرائیویٹ پلیسمنٹ میمورنڈم، سبسکرپشن ایگریمنٹ، اور اس طرح کے کسی بھی فنڈ کی دیگر متعلقہ دستاویزات کے ذریعے کی جائے گی اور ان کو مکمل طور پر پڑھا جانا چاہیے۔) کوئی بھی سرمایہ کاری یا پورٹ فولیو کمپنیوں کا ذکر کیا گیا، حوالہ دیا گیا، یا بیان کردہ A16z کے زیر انتظام گاڑیوں میں ہونے والی تمام سرمایہ کاری کے نمائندے نہیں ہیں، اور اس بات کی کوئی یقین دہانی نہیں ہو سکتی کہ سرمایہ کاری منافع بخش ہو گی یا مستقبل میں کی جانے والی دیگر سرمایہ کاری میں بھی ایسی ہی خصوصیات یا نتائج ہوں گے۔ Andreessen Horowitz کے زیر انتظام فنڈز کے ذریعے کی گئی سرمایہ کاری کی فہرست (ان سرمایہ کاری کو چھوڑ کر جن کے لیے جاری کنندہ نے a16z کو عوامی طور پر ظاہر کرنے کے ساتھ ساتھ عوامی طور پر تجارت کیے جانے والے ڈیجیٹل اثاثوں میں غیر اعلانیہ سرمایہ کاری کی اجازت فراہم نہیں کی ہے) https://a16z.com/investments پر دستیاب ہے۔ /.

اندر فراہم کردہ چارٹس اور گراف صرف معلوماتی مقاصد کے لیے ہیں اور سرمایہ کاری کا کوئی فیصلہ کرتے وقت ان پر انحصار نہیں کیا جانا چاہیے۔ ماضی کی کارکردگی مستقبل کے نتائج کا اشارہ نہیں ہے۔ مواد صرف اشارہ کردہ تاریخ کے مطابق بولتا ہے۔ کوئی بھی تخمینہ، تخمینہ، پیشن گوئی، اہداف، امکانات، اور/یا ان مواد میں بیان کیے گئے خیالات بغیر اطلاع کے تبدیل کیے جا سکتے ہیں اور دوسروں کی رائے سے مختلف یا اس کے برعکس ہو سکتے ہیں۔ اضافی اہم معلومات کے لیے براہ کرم https://a16z.com/disclosures دیکھیں۔