SNARK কর্মক্ষমতা পরিমাপ: ফ্রন্টেন্ড, ব্যাকএন্ড এবং ভবিষ্যত

একটি SNARK (সংক্ষিপ্ত নন-ইন্টারেক্টিভ আর্গুমেন্টস অফ নলেজ) হল ব্লকচেইন স্কেলেবিলিটি (যেমন, L2 রোলআপ) এবং গোপনীয়তার জন্য একটি গুরুত্বপূর্ণ ক্রিপ্টোগ্রাফিক আদিম ফাইন্ডিং অ্যাপ্লিকেশন। SNARKs কাউকে অবিশ্বস্ত যাচাইকারীর কাছে প্রমাণ করতে দেয় V (যেমন, ইথেরিয়াম ব্লকচেইন) যে তারা কিছু ডেটা জানে (যেমন, বৈধ লেনদেনের একটি ব্যাচ)। এটি প্রমাণ করার একটি নিষ্পাপ উপায় ডেটা পাঠাতে হবে V, যিনি সরাসরি এর বৈধতা পরীক্ষা করতে পারেন। একটি SNARK একই অর্জন করে, কিন্তু আরও ভাল খরচ সহ V. বিশেষ করে, একটি SNARK প্রুফ ডেটা নিজেই সমন্বিত নির্বোধের চেয়ে ছোট হওয়া উচিত। (আরো বিস্তারিত জানার জন্য, আমার পাঠ্যপুস্তকের খসড়াটি দেখুন, প্রমাণ, যুক্তি, এবং শূন্য জ্ঞান. SNARK-এর পরিচিতির জন্য, সারাহ মেইকলজন দেখুন উপহার a16z ক্রিপ্টোতে গ্রীষ্মকালীন গবেষণা সিরিজ.)

SNARK-এর জন্য যাচাইকরণের খরচ পরিবর্তিত হতে পারে, কিন্তু ভালভাবে বোঝা যায় এবং প্রায়ই বেশ ভাল। উদাহরণ স্বরূপ, PlonK প্রমাণ খরচ প্রায় 290,000 গ্যাস Ethereum-এ যাচাই করতে, যখন StarkWare-এর প্রমাণগুলির দাম প্রায় 5 মিলিয়ন গ্যাস। SNARKগুলি ব্লকচেইনের বাইরেও বিভিন্ন সেটিংসে সম্ভাব্যভাবে প্রযোজ্য - উদাহরণস্বরূপ দ্রুত কিন্তু অবিশ্বস্ত এর ব্যবহার সক্ষম করা সার্ভার এবং হার্ডওয়্যার. 

কিন্তু যেহেতু SNARK যাচাইকরণ সাধারণত সস্তা, তাই প্রযোজ্যতার প্রধান নির্ধারক হল SNARK প্রোভারের খরচ P. এই পোস্টে, SNARKs ব্যবহার করা কখন যুক্তিসঙ্গত তা নির্ধারণ করতে এই খরচগুলি কীভাবে অনুমান করা যায় এবং ভবিষ্যতে SNARKগুলি কীভাবে উন্নতি করতে পারে তা আমি ব্যাখ্যা করছি। এটি লক্ষণীয় যে এটি একটি দ্রুত-চলমান স্থান, এবং এই পোস্টে আলোচিত বেশ কয়েকটি প্রকল্প সক্রিয়ভাবে তাদের কর্মক্ষমতা উন্নত করছে।

কিন্তু প্রথম: কিভাবে SNARK গুলি মোতায়েন করা হয়

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, এবং বিভিন্ন গ্রাফ সমস্যা, পরিচিত SNARK গুলি বিদ্যমান যা এই ফ্রন্টএন্ড/ব্যাকএন্ড দৃষ্টান্তকে এড়িয়ে চলে এবং এর ফলে একটি অত্যন্ত দ্রুত প্রভার অর্জন করে। কিন্তু এই পোস্টের ফোকাস সাধারণ-উদ্দেশ্য SNARK-এর উপর।

আমরা দেখতে পাব, SNARK ব্যাকএন্ডের প্রভার খরচ বেড়ে যায় Cএর আকার রাখা C ছোটটি চ্যালেঞ্জিং হতে পারে, কারণ সার্কিট একটি অত্যন্ত সীমিত বিন্যাস যেখানে একটি গণনা প্রকাশ করা যায়। তারা গঠিত গেট দ্বারা সংযুক্ত পুতুল. প্রতিটি গেট g কিছু মান খাওয়ানো হয় এবং একটি প্রয়োগ করে খুব যারা মান সহজ ফাংশন. ফলাফল তারপর থেকে নির্গত তারের মাধ্যমে "ডাউনস্ট্রিম" গেট মধ্যে খাওয়ানো হয় g.

SNARK পরিমাপযোগ্যতা: এটি আসলে কত সময় নেয়?

মূল প্রশ্ন হল, SNARK প্রোভারটি আর কত সময় নেয়, কেবলমাত্র পুনরায় কার্যকর করার তুলনায় ψ তথ্যের উপর? উত্তর হল prover overhead SNARK-এর, আপেক্ষিক সরাসরি সাক্ষী পরীক্ষা. পরের অভিব্যক্তি সত্য বোঝায় যে, নিষ্পাপ প্রমাণ মধ্যে যা P পাঠায় w থেকে V, V চেক wকার্যকর করার মাধ্যমে এর বৈধতা ψ চালু কর. 

প্রোভার ওভারহেডকে "ফ্রন্টেন্ড ওভারহেড" এবং "ব্যাকএন্ড ওভারহেড" এ ভাঙা সহায়ক। যদি সার্কিট মূল্যায়ন C গেট-বাই-গেট হল F দৌড়ানোর চেয়ে গুণ বেশি ব্যয়বহুল ψ, তারপর আমরা বলি ফ্রন্টএন্ড ওভারহেড F. ব্যাকএন্ড প্রভার প্রয়োগ করলে C is B মূল্যায়নের চেয়ে গুণ বেশি ব্যয়বহুল C গেট-বাই-গেট, তারপর আমরা বলি যে ব্যাকএন্ড ওভারহেড B. মোট প্রভার ওভারহেড হল পণ্য, F·B. এই multiplicative ওভারহেড এমনকি যদি যথেষ্ট হতে পারে F এবং B স্বতন্ত্রভাবে বিনয়ী হয়। 

প্রস্তুতিতে, F এবং B উভয়ই প্রায় 1000 বা বড় হতে পারে। এর মানে হল প্রত্যক্ষ সাক্ষী যাচাইয়ের সাপেক্ষে মোট প্রোভার ওভারহেড 1 মিলিয়ন থেকে 10 মিলিয়ন বা তার বেশি হতে পারে। একটি ল্যাপটপে মাত্র এক সেকেন্ডের জন্য চলে এমন একটি প্রোগ্রাম সহজেই একটি SNARK প্রোভারের দিকে নিয়ে যেতে পারে যার জন্য দশ বা কয়েকশ দিনের গণনা সময় প্রয়োজন (একক-থ্রেডেড)। সৌভাগ্যবশত, এই কাজটি সাধারণত বিভিন্ন মাত্রার (SNARK-এর উপর নির্ভর করে) সমান্তরাল। 

সংক্ষেপে, আপনি যদি আজ একটি অ্যাপ্লিকেশনে একটি SNARK ব্যবহার করতে চান, তাহলে তিনটি জিনিসের মধ্যে একটি সত্য হওয়া দরকার:

1. একটি ল্যাপটপে সরাসরি সাক্ষী পরীক্ষা করতে এক সেকেন্ডেরও কম সময় লাগে।
2. প্রত্যক্ষ সাক্ষী পরীক্ষা একটি সার্কিটে প্রতিনিধিত্বের জন্য বিশেষভাবে উপযুক্ত, তাই ফ্রন্টএন্ড ওভারহেড ছোট।
3. আপনি SNARK প্রোভার শেষ হওয়ার জন্য দিন অপেক্ষা করতে ইচ্ছুক, এবং/অথবা বিশাল সমান্তরাল গণনা সংস্থানের জন্য অর্থ প্রদান করতে চান।

Tএই পোস্টের বাকি অংশ তিনি ব্যাখ্যা করেছেন যে ফ্রন্টএন্ড এবং ব্যাকএন্ড ওভারহেডগুলি কোথা থেকে আসে এবং আমি কীভাবে সেগুলিকে বিভিন্ন SNARK-এর জন্য অনুমান করি৷ আমরা তারপর উন্নতির জন্য সম্ভাবনা চালু করব. 

ফ্রন্টএন্ড এবং ব্যাকএন্ড আলাদা করা

ব্যাকএন্ড থেকে ফ্রন্টএন্ড সম্পূর্ণভাবে আলাদা করা চ্যালেঞ্জিং হতে পারে কারণ বিভিন্ন ব্যাকএন্ড বিভিন্ন ধরনের সার্কিট সমর্থন করে। তাই, ব্যাকএন্ডের উপর নির্ভর করে ফ্রন্টএন্ডগুলি ভিন্ন হতে পারে যার সাথে তারা ইন্টারফেস আশা করে।

SNARK ব্যাকএন্ডগুলি সাধারণত তথাকথিত গাণিতিক সার্কিটকে সমর্থন করে, যার অর্থ হল সার্কিটের ইনপুটগুলি কিছু সসীম ক্ষেত্রের উপাদান, এবং সার্কিটের গেট দুটি ক্ষেত্রের উপাদানের যোগ এবং গুণন সম্পাদন করে। এই সার্কিটগুলি মোটামুটিভাবে সরল-রেখার কম্পিউটার প্রোগ্রামগুলির সাথে মিলে যায় (কোনও শাখা নেই, শর্তসাপেক্ষ বিবৃতি ইত্যাদি) যা বীজগাণিতিক প্রকৃতির - অর্থাৎ, তাদের আদিম ডেটা টাইপ হল ক্ষেত্র উপাদান। 

বেশিরভাগ ব্যাকএন্ড প্রকৃতপক্ষে পাটিগণিত সার্কিটের একটি সাধারণীকরণকে সমর্থন করে যাকে প্রায়শই Rank-1 Constraint Satisfaction (R1CS) দৃষ্টান্ত বলা হয়। উল্লেখযোগ্য ব্যতিক্রম সঙ্গে গ্রোথ16 এবং এর পূর্বসূরীদের, এই SNARKগুলিকে অন্যান্য IR-কেও সমর্থন করার জন্য তৈরি করা যেতে পারে। উদাহরণস্বরূপ, স্টার্কওয়্যার বীজগণিত মধ্যবর্তী প্রতিনিধিত্ব (এআইআর) নামে কিছু ব্যবহার করে, যা একটি ধারণার মতোও। PlonKish পাটিগণিতকরণ যেটি PlonK এবং অন্যান্য ব্যাকএন্ড দ্বারা সমর্থিত হতে পারে। আরও সাধারণ IR-কে সমর্থন করার জন্য কিছু ব্যাকএন্ডের ক্ষমতা সেই IR তৈরি করে এমন ফ্রন্টএন্ডগুলির ওভারহেড কমাতে পারে। 

ব্যাকএন্ডগুলি সীমিত ক্ষেত্রের পরিপ্রেক্ষিতে পরিবর্তিত হয় যা তারা স্থানীয়ভাবে সমর্থন করে। আমি পরবর্তী বিভাগে এটি আরও আলোচনা করব।

ফ্রন্টএন্ডে বিভিন্ন পন্থা

কিছু (খুব বিশেষ) কম্পিউটার প্রোগ্রাম স্বাভাবিকভাবেই পাটিগণিত সার্কিটের সাথে মিলে যায়। একটি উদাহরণ হল কম্পিউটার প্রোগ্রাম যা কিছু ক্ষেত্রের উপর ম্যাট্রিক্সের নিষ্পাপ গুণন সম্পাদন করে। কিন্তু অধিকাংশ কম্পিউটার প্রোগ্রাম সরলরেখা বা বীজগণিত নয়। তারা প্রায়ই শর্তসাপেক্ষ বিবৃতি, পূর্ণসংখ্যা বিভাজন বা ফ্লোটিং পয়েন্ট পাটিগণিতের মতো ক্রিয়াকলাপগুলিকে জড়িত করে যা স্বাভাবিকভাবেই সসীম ক্ষেত্রের গাণিতিকের সাথে মিল রাখে না এবং আরও অনেক কিছু। এই ক্ষেত্রে, ফ্রন্টএন্ড ওভারহেড যথেষ্ট হবে। 

একটি জনপ্রিয় ফ্রন্টএন্ড পদ্ধতি হল সার্কিট তৈরি করা যা মূলত ধাপে ধাপে কিছু সাধারণ সিপিইউ চালায়, যাকে ভার্চুয়াল মেশিন (ভিএম)ও বলা হয়। ফ্রন্টএন্ড ডিজাইনাররা প্রকৃত কম্পিউটার প্রসেসরের জন্য সমাবেশ নির্দেশাবলীর অনুরূপ "আদিম ক্রিয়াকলাপ" এর একটি সেট নির্দিষ্ট করে। যে ডেভেলপাররা ফ্রন্টএন্ড ব্যবহার করতে চান তারা হয় সরাসরি অ্যাসেম্বলি ল্যাঙ্গুয়েজে "সাক্ষী-চেকিং প্রোগ্রাম" লিখবেন বা অন্য কিছু উচ্চ-স্তরের ভাষায় যেমন সলিডিটি, এবং তাদের প্রোগ্রামগুলি স্বয়ংক্রিয়ভাবে সমাবেশ কোডে সংকলিত হবে। 

উদাহরণস্বরূপ, স্টার্কওয়্যার কায়রো একটি অত্যন্ত সীমিত সমাবেশ ভাষা যেখানে সমাবেশ নির্দেশাবলী মোটামুটিভাবে একটি সীমিত ক্ষেত্রের উপর যোগ এবং গুণনের অনুমতি দেয়, ফাংশন কল করে এবং একটি অপরিবর্তনীয় (অর্থাৎ একবার লিখতে হবে) মেমরিতে পড়তে ও লিখতে পারে। কায়রো ভিএম হল একটি ভন নিউম্যান আর্কিটেকচার, যার অর্থ হল ফ্রন্টএন্ড দ্বারা উত্পাদিত সার্কিটগুলি মূলত একটি কায়রো প্রোগ্রামকে পাবলিক ইনপুট হিসাবে গ্রহণ করে এবং সাক্ষীর উপর প্রোগ্রামটি "চালনা" করে। কায়রো ভাষা টিউরিং কমপ্লিট — এর সীমিত নির্দেশনা সেট সত্ত্বেও, এটি আরও মানক আর্কিটেকচার অনুকরণ করতে পারে, যদিও এটি করা ব্যয়বহুল হতে পারে। কায়রো ফ্রন্টএন্ড কায়রো প্রোগ্রামগুলিকে কার্যকরী করে তোলে T আদিম নির্দেশাবলী যাকে "ডিগ্রী-" বলা হয়2 সঙ্গে AIR T সারি এবং প্রায় 50 কলাম." কি ঠিক এই মানে এই পোস্টের জন্য গুরুত্বপূর্ণ নয়, কিন্তু যতদূর SNARK প্রবক্তারা উদ্বিগ্ন, এটি প্রতিটির জন্য 50 থেকে 100টি গেট বিশিষ্ট সার্কিটের সাথে মিলে যায়। T কায়রো CPU এর ধাপ। 

RISC শূন্য কায়রোতে অনুরূপ পদ্ধতি গ্রহণ করে, কিন্তু ভার্চুয়াল মেশিন তথাকথিত হচ্ছে RISC-V আর্কিটেকচার, একটি সমৃদ্ধ সফ্টওয়্যার ইকোসিস্টেম সহ একটি ওপেন সোর্স আর্কিটেকচার যা জনপ্রিয়তা বৃদ্ধি পাচ্ছে৷ একটি খুব সাধারণ নির্দেশনা সেট হিসাবে, এটিকে সমর্থন করে এমন একটি দক্ষ SNARK ফ্রন্টএন্ড ডিজাইন করা তুলনামূলকভাবে সহজ হতে পারে (অন্তত জটিল আর্কিটেকচার যেমন x86 বা এআরএমের সাথে সম্পর্কিত)। মে হিসাবে, RISC শূন্য প্রোগ্রাম বাঁক হয় নির্বাহ T ডিগ্রী-5 এআইআর-এ আদিম RISC-V নির্দেশাবলী সহ 3T সারি এবং 160 কলাম. এই অন্তত সঙ্গে সার্কিট অনুরূপ 500 RISC-V CPU-এর প্রতি ধাপে গেট। অদূর ভবিষ্যতে আরও উন্নতি প্রত্যাশিত।

বিভিন্ন zkEVM প্রকল্প (যেমন, zkSync 2.0, Scroll, Polygon's zkEVM) ভার্চুয়াল মেশিনকে (duh) Ethereum ভার্চুয়াল মেশিন হিসেবে গ্রহণ করে। প্রতিটি ইভিএম নির্দেশকে একটি সমতুল্য "গ্যাজেটে" পরিণত করার প্রক্রিয়া (অর্থাৎ, নির্দেশ বাস্তবায়নকারী একটি অপ্টিমাইজড সার্কিট) সহজ কায়রো এবং RISC-V আর্কিটেকচারের তুলনায় যথেষ্ট বেশি জড়িত। এই এবং অন্যান্য কারণে, কিছু zkEVM প্রকল্প ইভিএম নির্দেশনা সেটটি সরাসরি বাস্তবায়ন করছে না বরং উচ্চ-স্তরের সলিডিটি প্রোগ্রামগুলিকে সার্কিটে পরিণত করার আগে অন্যান্য অ্যাসেম্বলি ভাষায় কম্পাইল করছে। এই প্রকল্পের কর্মক্ষমতা ফলাফল মুলতুবি আছে.

RISC-V এবং কায়রোর মতো "CPU এমুলেটর" প্রকল্পগুলি একটি একক সার্কিট তৈরি করে যা সংশ্লিষ্ট সমাবেশ ভাষার সমস্ত প্রোগ্রাম পরিচালনা করতে পারে। বিকল্প পন্থা হল "ASIC-এর মতো," বিভিন্ন প্রোগ্রামের জন্য বিভিন্ন সার্কিট তৈরি করে। এই ASIC-এর মতো পদ্ধতি কিছু প্রোগ্রামের জন্য ছোট সার্কিট তৈরি করতে পারে, বিশেষ করে যখন অ্যাসেম্বলি নির্দেশনা যা প্রোগ্রাম প্রতিটি টাইমস্টেপে এক্সিকিউট করে তা প্রোগ্রামের ইনপুটের উপর নির্ভর করে না। উদাহরণস্বরূপ, এটি সম্ভাব্যভাবে সরাসরি-লাইন প্রোগ্রামগুলির জন্য ফ্রন্টএন্ড ওভারহেড সম্পূর্ণরূপে এড়াতে পারে যেমন নেভ ম্যাট্রিক্স গুণন। কিন্তু ASIC পদ্ধতিও অত্যন্ত সীমিত বলে মনে হয়; যতদূর আমি জানি, পূর্বনির্ধারিত পুনরাবৃত্তি সীমা ছাড়াই লুপ সমর্থন করতে এটি কীভাবে ব্যবহার করবেন তা জানা নেই। 

ফ্রন্টএন্ড ওভারহেডের চূড়ান্ত উপাদানটি এই সত্য থেকে আসে যে সমস্ত SNARK সার্কিট ব্যবহার করে যা সসীম ক্ষেত্রের উপর কাজ করে। আপনার ল্যাপটপের CPU একটি একক মেশিন নির্দেশের সাথে দুটি পূর্ণসংখ্যাকে গুণ বা যোগ করতে পারে। যদি একটি ফ্রন্টএন্ড যথেষ্ট বড় বৈশিষ্ট্যযুক্ত একটি ক্ষেত্রের উপর একটি সার্কিট আউটপুট করে, তবে এটি সংশ্লিষ্ট ক্ষেত্রের অপারেশনের মাধ্যমে সেই গুণ বা যোগকে মূলত অনুকরণ করতে পারে। যাইহোক, একটি বাস্তব CPU-তে ফিল্ড অপারেশন বাস্তবায়নের জন্য সাধারণত অনেক মেশিন নির্দেশের প্রয়োজন হয় (যদিও কিছু আধুনিক প্রসেসরের নির্দিষ্ট ক্ষেত্রের জন্য স্থানীয় সমর্থন থাকে)। 

কিছু SNARK ব্যাকএন্ড অন্যদের তুলনায় আরো নমনীয় ক্ষেত্র পছন্দ সক্ষম করে। উদাহরণস্বরূপ, যদি ব্যাকএন্ড একটি ক্রিপ্টোগ্রাফিক গ্রুপ ব্যবহার করে G, সার্কিটের ক্ষেত্রকে উপাদানের সংখ্যার সাথে মেলাতে হবে G, যা সীমাবদ্ধ হতে পারে। উপরন্তু, সমস্ত ক্ষেত্র ব্যবহারিক FFT অ্যালগরিদম সমর্থন করে না। 

শুধুমাত্র একটি বাস্তবায়িত SNARK আছে, শেষ করা, যা স্থানীয়ভাবে নির্বিচারে (যথেষ্ট বড়) ক্ষেত্রের উপর গণনা সমর্থন করে। এর সাথে সাথে বংশধর, অন্যান্য SNARK সমর্থন করে এমন ক্ষেত্রগুলিতেও এটির সবচেয়ে দ্রুত পরিচিত কংক্রিট প্রোভার পারফরম্যান্স রয়েছে, তবে এর প্রমাণগুলি বর্তমানে অনেক ব্লকচেইন অ্যাপ্লিকেশনের জন্য খুব বড়। সাম্প্রতিক কাজ প্রমাণ আকার উন্নত করতে চায়, কিন্তু prover asymptotically ধীর এবং সেখানে মনে করা হয় বাধা ব্যবহারিকতা

কিছু প্রকল্প বিশেষ করে দ্রুত পাটিগণিত সহ ক্ষেত্রগুলিতে কাজ করার জন্য বেছে নিয়েছে। উদাহরণ স্বরূপ, Plonky2 এবং অন্যরা বৈশিষ্ট্য 2 এর একটি ক্ষেত্র ব্যবহার করে⁶⁴ - 2³² + 1 কারণ এই ক্ষেত্রের পাটিগণিত কম কাঠামোগত ক্ষেত্রের তুলনায় কয়েকগুণ দ্রুত প্রয়োগ করা যেতে পারে। যাইহোক, এই ধরনের একটি ছোট বৈশিষ্ট্য ব্যবহার করলে ক্ষেত্রের ক্রিয়াকলাপের মাধ্যমে পূর্ণসংখ্যার পাটিগণিতকে দক্ষতার সাথে উপস্থাপন করতে চ্যালেঞ্জ হতে পারে (যেমন, দুটি 32-বিট স্বাক্ষরবিহীন পূর্ণসংখ্যাকে গুণ করলে ক্ষেত্রের বৈশিষ্ট্যের চেয়ে বেশি ফলাফল পাওয়া যেতে পারে)। 

 কিন্তু যাই হোক না কেন, আজকের সব জনপ্রিয় SNARK-এর জন্য 128 বিট নিরাপত্তা (যাচাইকরণের খরচে উল্লেখযোগ্য বৃদ্ধি ছাড়া) অর্জন করতে, তাদের 2 এর থেকে বড় আকারের ক্ষেত্রে কাজ করতে হবে¹²⁸. যতদূর আমি বলতে পারি, এর মানে হল যে প্রতিটি ক্ষেত্রের অপারেশনের জন্য কমপক্ষে দশটি 64-বিট মেশিন গুণের প্রয়োজন হবে, এবং যথেষ্ট পরিমাণে সংযোজন এবং বিটওয়াইজ অপারেশন। তাই, সীমিত ক্ষেত্রগুলির উপর কাজ করে এমন সার্কিটের প্রয়োজনের কারণে একজনের অন্ততপক্ষে ফ্রন্টএন্ড ওভারহেডের একটি ক্রমকে ফ্যাক্টর করা উচিত। 

সংক্ষেপে বলতে গেলে, একটি ভার্চুয়াল মেশিন বিমূর্ততা ব্যবহার করে বিদ্যমান ফ্রন্টএন্ডগুলি ভার্চুয়াল মেশিনের প্রতি ধাপে 100x থেকে 1000x গেট সহ সার্কিট তৈরি করে এবং সম্ভবত আরও জটিল ভার্চুয়াল মেশিনের জন্য আরও বেশি। সর্বোপরি, সসীম ক্ষেত্র পাটিগণিত আধুনিক প্রসেসরগুলিতে অনুরূপ নির্দেশাবলীর চেয়ে কমপক্ষে 10x ধীরগতির (যদি প্রসেসরের নির্দিষ্ট ক্ষেত্রের জন্য অন্তর্নির্মিত সমর্থন থাকে তবে সম্ভাব্য ব্যতিক্রমগুলি সহ)। একটি "ASIC ফ্রন্টএন্ড পদ্ধতি" এই ওভারহেডগুলির কিছু কমাতে পারে কিন্তু বর্তমানে এটি যে ধরনের প্রোগ্রামগুলিকে সমর্থন করতে পারে তার মধ্যে সীমাবদ্ধ৷

ব্যাকএন্ড বাধা কি?

সার্কিট-সন্তুষ্টির জন্য SNARK গুলি সাধারণত একটি তথ্য-তাত্ত্বিকভাবে সুরক্ষিত প্রোটোকলের সমন্বয়ে ডিজাইন করা হয় যাকে বলা হয় "বহুপদী IOPএকটি ক্রিপ্টোগ্রাফিক প্রোটোকল সহ একটি "বহুপদ প্রতিশ্রুতি প্রকল্প" বেশিরভাগ ক্ষেত্রে, প্রোভারের জন্য কংক্রিট বাধা হল বহুপদী প্রতিশ্রুতি প্রকল্প। বিশেষ করে, এই SNARK-এর প্রভার ক্রিপ্টোগ্রাফিকভাবে এক বা একাধিক বহুপদে প্রতিশ্রুতিবদ্ধ থাকে যার ডিগ্রি (অন্তত) |C|, সার্কিটে গেটের সংখ্যা C. 

পরিবর্তে, বহুপদী প্রতিশ্রুতি স্কিমের মধ্যে কংক্রিট বাধা নির্ভর করবে ব্যবহৃত স্কিম এবং সার্কিট আকারের উপর। তবে এটি সর্বদা নিম্নলিখিত তিনটি ক্রিয়াকলাপের মধ্যে একটি হবে: কম্পিউটিং এফএফটি, একটি ক্রিপ্টোগ্রাফিক গ্রুপে সূচক বা মার্কেল-হ্যাশিং. সার্কিটটি ছোট হলেই মার্কেল-হ্যাশিং সাধারণত একটি বাধা হয়ে দাঁড়ায়, তাই আমরা এটি নিয়ে আর আলোচনা করব না। 

বিচ্ছিন্ন লগের উপর ভিত্তি করে বহুপদ প্রতিশ্রুতি

একটি ক্রিপ্টোগ্রাফিক গ্রুপে বিচ্ছিন্ন লগারিদম সমস্যার কঠোরতার উপর ভিত্তি করে বহুপদী প্রতিশ্রুতিতে G (কেজেডিজি, বুলেটপ্রুফ, Dory তে, এবং হাইরাক্স-কমিট, prover একটি গণনা আছে Pedersen ভেক্টর প্রতিশ্রুতি বহুপদীর সহগ পর্যন্ত। এটি বহুপদী ডিগ্রীর সমান আকারের একটি মাল্টি-এক্সপোনেনশিয়েশন জড়িত। SNARK-এ, এই ডিগ্রী সাধারণত আকার হয় |C| সার্কিটের C.

নির্বোধভাবে সম্পন্ন করা হয়েছে, আকারের একটি মাল্টি-এক্সপোনানিয়েশন |C| প্রায় 1.5 প্রয়োজন·|C|·লগ ইন করুন |G| ≈ 400·|C| গ্রুপ অপারেশন, যেখানে |G| গ্রুপে উপাদানের সংখ্যা নির্দেশ করে G. যাইহোক, পিপেনগারের অ্যালগরিদম নামে একটি পদ্ধতি রয়েছে, যা মোটামুটি লগের একটি ফ্যাক্টর দ্বারা এটি কমাতে পারে |C|. বড় সার্কিটের জন্য (বলুন, |C| ≥ 225), এই লগ |C| ফ্যাক্টর 25 বা তার বেশি হতে পারে, অর্থাৎ, বড় সার্কিটের জন্য, আমরা আশা করি যে পেডারসেন ভেক্টর প্রতিশ্রুতি 10 এর একটু বেশি দিয়ে গণনাযোগ্য হতে পারে·|C| গ্রুপ অপারেশন। প্রতিটি গ্রুপ অপারেশন পালাক্রমে (খুব রুক্ষ বলপার্ক হিসাবে) একটি সীমিত ফিল্ড অপারেশনের চেয়ে প্রায় 10 গুণ ধীর হতে থাকে। এই বহুপদী প্রতিশ্রুতিগুলি ব্যবহার করে SNARKগুলি ব্যয়বহুল P প্রায় 100 হিসাবে·|C| মাঠ অপারেশন. 

দুর্ভাগ্যবশত, উপরের 100x ফ্যাক্টরের উপরে বিদ্যমান SNARK-এর অতিরিক্ত ওভারহেড রয়েছে। উদাহরণ স্বরূপ:

• স্পার্টা লোকএর prover, যা Hyrax বহুপদী প্রতিশ্রুতি ব্যবহার করে, করতে হবে |C|^½ অনেক মাল্টি-এক্সপোনেশনেশন প্রতিটি আকার |C|^½, মোটামুটি দুটির একটি ফ্যাক্টর দ্বারা Pippenger এর অ্যালগরিদম থেকে স্পীডআপকে দুর্বল করে। 
• In গ্রোথ16, P একটি পেয়ারিং-ফ্রেন্ডলি গ্রুপের উপর কাজ করতে হবে, যাদের ক্রিয়াকলাপগুলি সাধারণত এমন গ্রুপগুলির তুলনায় কমপক্ষে 2x ধীর হয় যেগুলি জুটি বান্ধব নয়৷ P এছাড়াও 3টির পরিবর্তে 1টি বহু-বিশ্লেষণ সম্পাদন করতে হবে। একত্রিত হলে, এর ফলে 6-এর তুলনায় কমপক্ষে একটি অতিরিক্ত ফ্যাক্টর-100 ধীর হয়ে যায়·|C| উপরে অনুমান। 
• জাতের বড়ো সামুদ্রিক মাছ এবং PlonK এছাড়াও জোড়ার প্রয়োজন, এবং তাদের প্রোভারগুলিকে 3টির বেশি বহুপদে প্রতিশ্রুতিবদ্ধ করতে হবে। 
• যে কোন SNARK ব্যবহার করে বুলেটপ্রুফ (যেমন, হ্যালো ১, যা মোটামুটিভাবে PlonK কিন্তু KZG বহুপদী প্রতিশ্রুতিগুলির পরিবর্তে বুলেটপ্রুফ সহ), প্রতিশ্রুতি স্কিমের "উদ্বোধন" পর্বে প্রযোজককে লগারিদমিকভাবে অনেক মাল্টি-এক্সপোনেন্টিয়েশন গণনা করতে হয় এবং এটি মূলত যেকোন পিপেঞ্জার গতিকে মুছে ফেলে। 

সংক্ষেপে, পেডারসেন ভেক্টর প্রতিশ্রুতি ব্যবহার করে পরিচিত SNARK-এর ব্যাকএন্ড ওভারহেড কমপক্ষে 200x এবং 1000x বা তার বেশি পর্যন্ত রয়েছে। 

অন্যান্য বহুপদ প্রতিশ্রুতি

অন্যান্য বহুপদ প্রতিশ্রুতি ব্যবহার করে SNARK-এর জন্য (যেমন শুক্র এবং Ligero-কমিট), বাধা হল যে prover বড় FFT সঞ্চালন প্রয়োজন. উদাহরণস্বরূপ, কায়রো দ্বারা উত্পাদিত ডিগ্রি -2 এআইআরগুলিতে (51টি কলাম সহ এবং T সারি, কায়রো সিপিইউ-এর প্রতি ধাপে একটি), স্টার্কওয়্যার-এর নিয়োজিত প্রোভার প্রতি কলামে কমপক্ষে 2 এফএফটি করে, এর মধ্যে দৈর্ঘ্য 16 ·T এবং 32 ·T. ধ্রুবক 16 এবং 32 স্টার্কওয়্যার দ্বারা সেট করা FRI-এর অভ্যন্তরীণ পরামিতিগুলির উপর নির্ভর করে এবং হ্রাস করা যেতে পারে — তবে যাচাইকরণের বর্ধিত খরচে। 

আশাবাদী, দৈর্ঘ্যের একটি FFT 32·T প্রায় 64 লাগে·T·লগ(32T) ক্ষেত্রের গুণন। এর মানে হল যে এমনকি অপেক্ষাকৃত ছোট মানগুলির জন্য T (যেমন, T ≥ 2²⁰), প্রতি কলামে ফিল্ড অপারেশনের সংখ্যা কমপক্ষে ৬৪টি·25·T= 1600·T. তাই ব্যাকএন্ড ওভারহেড অন্তত হাজার হাজারে প্রদর্শিত হবে। তদ্ব্যতীত, এটা সম্ভব যে বড় এফএফটিগুলি ফিল্ড অপারেশনের তুলনায় মেমরি ব্যান্ডউইথ দ্বারা আরও বেশি বাধাগ্রস্ত হয়। 

কিছু প্রেক্ষাপটে, SNARK-এর ব্যাকএন্ড ওভারহেড যেগুলি বড় FFT সম্পাদন করে তা প্রুফ অ্যাগ্রিগেশন নামক একটি কৌশলের মাধ্যমে প্রশমিত করা যেতে পারে। rollups জন্য, এই যে মানে হবে P (রোলআপ পরিষেবা) লেনদেনের একটি বড় ব্যাচকে 10টি ছোট ব্যাচে বিভক্ত করে। প্রতিটি ছোট ব্যাচের জন্য i, P একটি SNARK প্রমাণ তৈরি করে πi ব্যাচ এর বৈধতা. কিন্তু P এই প্রমাণগুলি Ethereum-এ পোস্ট করে না, কারণ এটি গ্যাস খরচ প্রায় 10-গুণ বৃদ্ধির দিকে পরিচালিত করবে। পরিবর্তে, SNARK আবার প্রয়োগ করা হয়েছে, এবার একটি প্রমাণ তৈরি করতে π যে প্রতিষ্ঠা P জানে π₁ ...,π₁₀. অর্থাৎ সাক্ষী যে P দাবী জানার দশটি প্রমাণ π₁,…,π₁₀, এবং প্রত্যক্ষ সাক্ষী পরীক্ষা প্রতিটি প্রমাণের জন্য SNARK যাচাইকরণ পদ্ধতি প্রয়োগ করে। এই একক প্রমাণ π Ethereum এ পোস্ট করা হয়। 

বহুপদী প্রতিশ্রুতি যেমন FRI এবং Ligero-কমিটের মধ্যে, একটি শক্তিশালী উত্তেজনা রয়েছে P সময় এবং V খরচ, অভ্যন্তরীণ পরামিতিগুলি একটি গাঁট হিসাবে কাজ করে যা একটি অন্যটির জন্য বাণিজ্য করতে পারে। থেকে π₁ ,…,π₁₀ Ethereum পোস্ট করা হয় না, গাঁট টিউন করা যাবে তাই এই প্রমাণ বড়, এবং তাদের উত্পাদন দ্রুত হয়. শুধুমাত্র SNARK-এর চূড়ান্ত প্রয়োগে, একত্রে π₁ ,…,π₁₀ একটি একক প্রমাণ মধ্যে π, একটি ছোট প্রমাণ নিশ্চিত করতে প্রতিশ্রুতি স্কিম কনফিগার করা প্রয়োজন কি? 

স্টার্কওয়্যার প্রমাণ একত্রিতকরণ স্থাপনের পরিকল্পনা করেছে imminently. এটি যেমন প্রকল্পের ফোকাস Plonky2.

SNARK স্কেলেবিলিটির অন্যান্য বাধাগুলি কী কী?

এই পোস্ট prover উপর দৃষ্টি নিবদ্ধ করা হয়েছে সময়, কিন্তু অন্যান্য প্রভার খরচ এছাড়াও মাপযোগ্যতা বাধা হতে পারে. উদাহরণস্বরূপ, অনেক SNARK ব্যাকএন্ডের জন্য প্রোভারকে প্রতিটি গেটের জন্য বেশ কয়েকটি ফিল্ড উপাদান সংরক্ষণ করতে হবে C, এবং এই স্থান খরচ বিশাল হতে পারে. উদাহরণস্বরূপ, একটি প্রোগ্রাম ψ একটি ল্যাপটপে এক সেকেন্ডে চালানো আধুনিক প্রসেসরে সম্ভবত এক বিলিয়ন আদিম ক্রিয়াকলাপ সম্পাদন করতে পারে। আমরা দেখেছি, সাধারণভাবে একজনের আশা করা উচিত C এই ধরনের অপারেশন প্রতি 100 টিরও বেশি গেট প্রয়োজন। এর অর্থ হল 100 বিলিয়ন গেট, যা SNARK-এর উপর নির্ভর করে, এর অর্থ হতে পারে দশ বা শত টেরাবাইট স্থান P. 

আরেকটি উদাহরণ: অনেক জনপ্রিয় SNARK (যেমন, PlonK, জাতের বড়ো সামুদ্রিক মাছ, গ্রোথ16) একটি সুগঠিত "প্রমাণ কী" তৈরি করতে একটি জটিল "বিশ্বস্ত সেটআপ অনুষ্ঠান" প্রয়োজন। যা prover দ্বারা সংরক্ষণ করা আবশ্যক. আমি যতদূর জানি, দ এই ধরনের সবচেয়ে বড় অনুষ্ঠান প্রায় 2 এর সাথে সার্কিট সমর্থন করতে সক্ষম একটি প্রমাণী কী তৈরি করেছে²⁸≈250 মিলিয়ন গেট। প্রমাণকারী কীটি আকারে কয়েক ডজন গিগাবাইট। 

প্রেক্ষাপটে যেখানে প্রমাণ একত্রীকরণ সম্ভব, এই বাধাগুলি যথেষ্টভাবে প্রশমিত করা যেতে পারে। 

সামনের দিকে তাকিয়ে আছে: আরও স্কেলেবল SNARK-এর সম্ভাবনা

ফ্রন্টএন্ড এবং ব্যাকএন্ড ওভারহেড উভয়ই তিন মাত্রার বা তার বেশি হতে পারে। আমরা কি আশা করতে পারি যে অদূর ভবিষ্যতে এগুলি উল্লেখযোগ্যভাবে কমে আসবে? 

আমি মনে করি আমরা করব - একটি বিন্দু পর্যন্ত। প্রথমত, আজকে দ্রুততম ব্যাকএন্ড (যেমন, স্পার্টা লোক এবং শেষ করা, এবং অন্যান্য SNARK যেগুলিকে একত্রিত করে সম-চেক প্রোটোকল বহুপদী প্রতিশ্রুতি সহ) বড় প্রমাণ রয়েছে - সাধারণত সার্কিটের আকারে বর্গমূল - তাই লোকেরা সত্যিই সেগুলি ব্যবহার করছে না। আমি আশা করি প্রুফ সাইজ এবং ভেরিফাইয়ারের সময় অদূর ভবিষ্যতে ছোট-প্রুফ SNARK-এর সাথে গভীরতা-এক রচনার মাধ্যমে অর্থপূর্ণভাবে হ্রাস পাবে। প্রুফ অ্যাগ্রিগেশনের মতোই, এর মানে হল একজন প্রোভার প্রথমে একটি SNARK প্রমাণ তৈরি করবে π সঙ্গে "দ্রুত-প্রমাণ, বড়-প্রমাণ" SNARK, কিন্তু পাঠান না π থেকে V। বরং, P একটি প্রমাণ তৈরি করতে একটি ছোট-প্রমাণ SNARK ব্যবহার করবে π' যে এটা জানে π, এবং পাঠাও π' থেকে V. এটি আজ জনপ্রিয় SNARK-এর ব্যাকএন্ড ওভারহেডের মাত্রার একটি ক্রম শেভ করতে পারে। 

দ্বিতীয়ত, হার্ডওয়্যার ত্বরণ সাহায্য করতে পারে। একটি খুব মোটামুটি সাধারণ নিয়ম হল যে GPU গুলি CPU-গুলির তুলনায় 10x গতির এবং ASICগুলি GPUগুলির তুলনায় 10x গতিসম্পন্ন কিনতে পারে৷ যাইহোক, এই ফ্রন্টে আমার তিনটি উদ্বেগ রয়েছে। প্রথমত, বড় এফএফটি ফিল্ড অপারেশনের পরিবর্তে মেমরি ব্যান্ডউইথের দ্বারা বাধাগ্রস্ত হতে পারে, তাই SNARK যেগুলি এই ধরনের এফএফটি সম্পাদন করে তারা বিশেষ হার্ডওয়্যার থেকে সীমিত গতি দেখতে পারে। দ্বিতীয়ত, যদিও এই পোস্টটি বহুপদী প্রতিশ্রুতি বাধার উপর দৃষ্টি নিবদ্ধ করেছে, অনেক SNARK-এর জন্য প্রোভারকে অন্যান্য অপারেশন করতে হবে যেগুলি শুধুমাত্র সামান্য কম ব্যয়বহুল। সুতরাং বহুপদী প্রতিশ্রুতি বাধা ভঙ্গ করা (যেমন, মাল্টি এক্সপোনেশনেশনের গতি বাড়াচ্ছে বিচ্ছিন্ন-লগ-ভিত্তিক SNARK-তে) একটি নতুন বাধা অপারেশন ছেড়ে যেতে পারে যা পুরানোটির চেয়ে অনেক বেশি ভাল নয়। (উদাহরণস্বরূপ, Groth16, Marlin, এবং PlonK সহ SNARK-এ বহু-বিশ্লেষণ ছাড়াও এফএফটি-এর প্রবাদ রয়েছে।) অবশেষে, ক্ষেত্র এবং উপবৃত্তাকার বক্ররেখা যা সবচেয়ে দক্ষ SNARK-এর দিকে নিয়ে যায় কিছু সময়ের জন্য বিকশিত হতে পারে এবং এটি ASIC-ভিত্তিক প্রোভার ত্বরণের জন্য চ্যালেঞ্জ তৈরি করতে পারে।

ফ্রন্টএন্ডের দিকে, আমরা ক্রমবর্ধমানভাবে দেখতে পাচ্ছি যে কায়রো, RISC জিরো, zkEVM এবং অন্যদের মতো প্রকল্পগুলির "CPU এমুলেটর" পদ্ধতি আসলে CPU নির্দেশনা সেটের জটিলতার সাথে (কর্মক্ষমতার পরিপ্রেক্ষিতে) বেশ ভাল স্কেল করে। প্রকৃতপক্ষে, এটি অবিকল বিভিন্ন zkEVM প্রকল্পের আশা। এর অর্থ হতে পারে যে, ফ্রন্টএন্ডের ওভারহেড তিনটি বা তার বেশি মাত্রার রয়ে গেলেও, ফ্রন্টএন্ডগুলি VM সমর্থন করতে পরিচালনা করে যা ক্রমবর্ধমানভাবে বাস্তব 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 দেখুন।