ابزاری برای تشخیص قراردادهای هوشمند دگرگونی

یک فرض مهم امنیتی اتریوم این است که کد قرارداد هوشمند تغییرناپذیر است و بنابراین نمی‌توان آن را پس از استقرار در بلاک چین تغییر داد. در عمل، برخی از قراردادهای هوشمند می توان تغییر - حتی پس از استقرار آنها. با چند ترفند هوشمندانه، می توانید قراردادهای هوشمند دگرگونی ایجاد کنید کهدگردیسی” به چیز دیگری – و با درک آنچه که آنها را ممکن می کند، می توانید آنها را شناسایی کنید.

قراردادهای هوشمند دگرگونی قابل تغییر هستند، به این معنی که توسعه دهندگان می توانند کد داخل آنها را تغییر دهند. این قراردادهای هوشمند خطری جدی برای کاربران وب 3 ایجاد می کند که به کدهایی اعتماد می کنند که انتظار دارند با یکپارچگی مطلق اجرا شود، به خصوص که بازیگران بد می توانند از این توانایی تغییر شکل سوء استفاده کنند. تصور کنید مهاجمی از این تکنیک برای "فرش کردن" افرادی استفاده می‌کند که در قراردادی هوشمند که نمی‌دانند دگرگونی است، توکن‌هایی را به کار می‌گیرند. حملات بر این اساس و موارد مشابه می‌تواند کلاهبرداران را برای شکار مردم تجهیز کند و به طور کلی اعتماد به سیستم‌های غیرمتمرکز را تضعیف کند.

برای تجزیه و تحلیل اینکه آیا یک قرارداد هوشمند دارای ویژگی‌های دگرگونی است، من ساده ساختم آشکارساز قرارداد دگرگونی (الهام گرفته شده از کار اصلی و بر اساس جیسون کارور, 0 سنو دیگران). هرکسی می‌تواند از این ابزار برای بررسی اینکه آیا یک قرارداد معین دارای پرچم‌های قرمز است که می‌تواند پتانسیل دگرگونی را نشان دهد، استفاده کند. این روش ضد احمق نیست: فقط به این دلیل که یک قرارداد هوشمند یک پرچم را نشان می دهد، به این معنی نیست که لزوماً دگرگونی است. و فقط به این دلیل که اینطور نیست، به این معنی نیست که ایمن است. چکر فقط یک ارزیابی اولیه سریع از یک قرارداد ارائه می دهد قدرت بر اساس شاخص های ممکن دگرگون شود. 

کاربران Web3 باید خود را با تهدیدات ناشی از قراردادهای دگرگونی آشنا کنند تا بتوانند مراقب حملات احتمالی باشند و از آن اجتناب کنند. کیف پول ها و نمایه سازهای بلاک چین می توانند با هشدار دادن به کاربران قبل از تعامل با یک قرارداد هوشمند که ممکن است دارای ویژگی های دگرگونی باشد، کمک کنند. این ابزار برای کمک به آموزش مردم در مورد این تهدید بالقوه… و دفاع در برابر آن در نظر گرفته شده است.

تشخیص قراردادهای هوشمند دگرگونی

La آشکارساز قرارداد دگرگونی من شش ویژگی را تجزیه و تحلیل کردم که ممکن است دگرگونی یک قرارداد هوشمند را نشان دهد.

1. 1. آیا از کد دگرگونی شناخته شده برای استقرار قرارداد استفاده شده است؟ اگر بایت‌کد دگرگونی شناخته شده - کد سطح پایین‌تر و قابل خواندن توسط ماشین مجازی که قراردادهای هوشمند اتریوم، معمولاً در Solidity نوشته می‌شود، پس از کامپایل شدن به آن تبدیل می‌شود - در تراکنش برای استقرار یک قرارداد هوشمند مشخص نشان داده می‌شود، این یک پرچم قرمز بزرگ است. در بخش‌های بعدی، یکی از این نمونه‌ها از بایت کد دگرگونی توسعه‌یافته توسط 0age را مورد بحث قرار خواهیم داد. یک هشدار مهم: تغییرات بالقوه بی شماری از بایت کد دگرگونی وجود دارد که تشخیص همه انواع را دشوار می کند. با این حال، آشکارساز با اسکن برای نمونه های شناخته شده، میوه های کم آویزان را برای مهاجمانی که صرفاً در حال کپی و چسباندن نمونه های موجود هستند حذف می کند.
   2. آیا کد قرارداد هوشمند می تواند خود تخریب شود؟ برای جایگزینی کد در یک قرارداد - یک مرحله کلیدی در ایجاد یک قرارداد دگرگونی - یک توسعه دهنده ابتدا باید کد از قبل موجود را حذف کند. تنها راه برای انجام این کار استفاده از اپکد SELFDESTRUCT، دستوری که دقیقاً همان کاری را انجام می دهد که به نظر می رسد - تمام کدها و فضای ذخیره سازی را در یک آدرس قرارداد داده شده پاک می کند. وجود رمز خود ویرانگر در یک قرارداد، دگرگونی آن را ثابت نمی کند. با این حال، سرنخی ارائه می دهد که قرارداد قدرت دگرگونی داشته باشید و به هر حال ارزش دانستن آن را دارد که آیا قراردادهایی که به آنها تکیه می کنید می توانند خود را بمباران کنند یا خیر.
   3. آیا قرارداد هوشمند با کد از جای دیگری تماس می گیرد؟ اگر قرارداد هوشمند مورد نظر نتواند مستقیماً خود تخریب شود، ممکن است همچنان بتواند خود را با استفاده از اپکد DELEGATECALL. این Opcode به یک قرارداد هوشمند اجازه می دهد تا به صورت پویا کدی را که در قرارداد هوشمند دیگری زندگی می کند بارگیری و اجرا کند. حتی اگر قرارداد هوشمند حاوی اپکد SELFDESTRUCT نباشد، می‌تواند از DELEGATECALL برای بارگیری کدهای خود تخریب شونده از جای دیگری استفاده کند. در حالی که عملکرد DELEGATECALL مستقیماً دگرگونی یک قرارداد هوشمند را نشان نمی دهد، این یک سرنخ احتمالی - و یک مشکل امنیتی بالقوه - است که شایان ذکر است. هشدار داده شود که این اندیکاتور پتانسیل ایجاد بسیاری از موارد مثبت کاذب را دارد. 
   4. آیا قرارداد دیگری این قرارداد را مستقر کرده است؟ قراردادهای دگرگونی می توانند مستقر شوند فقط توسط سایر قراردادهای هوشمند این به این دلیل است که قراردادهای دگرگونی توسط یک اپکد دیگر فعال می شوند که فقط توسط سایر قراردادهای هوشمند به نام CREATE2 قابل استفاده است. (ما در بخش بعدی بیشتر در مورد CREATE2 بحث خواهیم کرد - چگونه کار می کند و چرا اهمیت دارد.) این ویژگی یکی از کمترین شاخص های دگرگونی ممکن است. این یک پیش شرط ضروری اما ناکافی است. اسکن برای این ویژگی احتمالاً بسیاری از موارد مثبت کاذب را به همراه خواهد داشت – اما دانستن آن اطلاعات ارزشمندی است زیرا می‌تواند شک و تردید را ایجاد کند و دلیلی برای بررسی دقیق قرارداد ارائه دهد، به خصوص اگر قرارداد هوشمند حاوی کد عملیاتی باشد که در ادامه توضیح داده شد.
   5. آیا قرارداد توسعه‌دهنده حاوی کد آپشن CREATE2 است؟ همانطور که در بالا ذکر شد، استقرار از طریق CREATE2 یک پیش شرط ضروری برای دگرگونی است. اگر قرارداد توسعه‌دهنده حاوی کد آپشن CREATE2 باشد، ممکن است نشان دهد که از CREATE2 برای استقرار قرارداد مورد نظر استفاده کرده است. اگر توسعه دهنده واقعاً از CREATE2 برای استقرار قرارداد مذکور استفاده کرده باشد، در حالی که این بدان معنا نیست که قرارداد لزوماً دگرگونی است، به این معنی است که قدرت دگرگونی باشد و ممکن است عاقلانه باشد که با احتیاط ادامه دهید و بیشتر تحقیق کنید. باز هم، مراقب مثبت کاذب باشید: ایجاد 2 مقدار زیادی از استفاده های مشروع، از جمله تقویت راه حل های مقیاس بندی "لایه 2". و ایجاد کیف پول های قرارداد هوشمند که می تواند وب3 را بهبود بخشد، آسان تر می کند ورود کاربر و گزینه های بازیابی کلیدی
   6. کد تغییر کرد؟ این واضح ترین حرف است، اما تنها پس از تغییر شکل یک قرارداد دگرگونی ظاهر می شود. اگر هش کد قرارداد هوشمند - یک شناسه رمزنگاری منحصر به فرد - با زمانی که قرارداد در ابتدا اجرا شد متفاوت است، احتمالاً کد حذف، جایگزین یا تغییر یافته است. اگر هش‌ها دیگر مطابقت نداشته باشند، چیزی در مورد کد تغییر کرده است و ممکن است قرارداد دگرگونی داشته باشد. این پرچم مطمئن‌ترین شاخص دگرگونی است، اما به پیش‌بینی یا جلوگیری از شکل‌گیری کمکی نمی‌کند، زیرا فقط بررسی می‌کند که قبلاً اتفاق افتاده است.

علاوه بر ساخت یک ابزار خط فرمان ساده برای آشکارساز قرارداد دگرگونی، چند نمونه قرارداد هوشمند ساختم که سناریوی شرط بندی قرارداد دگرگونی کلاهبرداری را نشان می دهد، که در بخش بعدی توضیح می دهم. تمام کدها در این موجود است مخزن GitHub. 

چگونه یک بازیگر بدخواه می تواند از قراردادهای دگرگونی برای سرقت سرمایه مردم استفاده کند

در اینجا نحوه استفاده شخصی از قرارداد هوشمند دگرگونی به عنوان بخشی از کلاهبرداری آمده است. 

اول مرحله راه اندازی است. مهاجم یک قرارداد هوشمند را در یک آدرس خاص در بلاک چین با استفاده از دو ابزار مستقر می کند: بایت کد دگرگونی و کد آپدیت CREATE2. (ما بعداً در مورد هر دوی این مفاهیم توضیح خواهیم داد.) سپس بایت کد دگرگونی همان کاری را انجام می دهد که نامش نشان می دهد و "مورف" می کند. در اینجا، به a تبدیل می شود قرارداد staking جایی که کاربران می توانند توکن های ERC-20 را به اشتراک بگذارند. (دوباره، بعداً در مورد جزئیات این ترفند شکل‌گیری صحبت خواهیم کرد. قول بده!)

بعد طعمه و سوئیچ می آید. کاربران ناآگاه، توکن‌های خود را در این قرارداد سهیم می‌کنند، و به دلیل امکان کسب بازدهی یا مزایای دیگری فریب می‌خورند. سپس مهاجم تمام کد سهام و "وضعیت" - ذخیره سازی یا حافظه بلاک چین - را در این آدرس قرارداد هوشمند با استفاده از اپکد SELFDESTRUCT در بخش قبل مورد بحث قرار گرفت. (لازم به ذکر است که توکن ها - که به عنوان بخشی از یک قرارداد جداگانه ERC-20 وجود دارند - باقی می مانند و تحت تأثیر قرارداد خود ویرانگر قرار نمی گیرند.)

در نهایت، قالیچه کش. مهاجم از همان بایت کد دگرگونی استفاده شده در مرحله راه‌اندازی مجدداً برای «قرار دادن مجدد» یک قرارداد جدید استفاده می‌کند. این قرارداد جدید به همان آدرسی مستقر می شود که اخیراً توسط قرارداد خود ویرانگر تخلیه شده است. با این حال، این بار، بایت کد به یک قرارداد مخرب تبدیل می شود (دوباره، بعداً توضیح خواهیم داد) به یک قرارداد مخرب که می تواند تمام توکن های موجود در آدرس قرارداد را بدزدد. کلاهبرداری کامل شد 

خطراتی که قراردادهای هوشمند دگرگونی ایجاد می‌کنند، اکنون به وضوح آشکار شده‌اند. اما ممکن است هنوز از خود بپرسید که این ترفند دگرگونی در واقع چگونه کار می کند؟ برای درک آن، باید عمیق‌تر در سطح بایت کد جستجو کنید. 

چگونه CREATE2 امکان دگرگونی را باز می کند 

ایجاد 2 یک آپکد آپگرید است، به اتریوم معرفی شد در فوریه 2019، که روش جدیدی برای استقرار قراردادهای هوشمند ارائه می دهد. 

CREATE2 به توسعه دهندگان کنترل بیشتری نسبت به قبل بر روی استقرار قراردادهای هوشمند خود می دهد. اپکد اصلی CREATE کنترل آدرس مقصد را برای یک قرارداد هوشمند برای توسعه دهندگان دشوار می کند. با CREATE2، افراد می توانند آدرس یک قرارداد هوشمند خاص را از قبل کنترل کرده و بدانند، قبل از اینکه واقعاً آن را در بلاک چین مستقر کنند. این پیش آگاهی - به علاوه برخی ترفندهای هوشمندانه - چیزی است که افراد را قادر می سازد قراردادهای هوشمند دگرگونی ایجاد کنند. 

CREATE2 چگونه می تواند آینده را پیش بینی کند؟ محاسبه Opcode قطعی است: تا زمانی که ورودی ها تغییر نکنند، آدرس تعیین شده توسط CREATE2 تغییر نخواهد کرد. (حتی کوچکترین تغییر باعث می شود که استقرار در جای دیگری اتفاق بیفتد.)

به طور دقیق تر، CREATE2 تابعی است که چند عنصر را با هم ترکیب و هش می کند. اول، آدرس توزیع کننده (یا فرستنده) را شامل می شود: قرارداد هوشمند آغاز کننده که به عنوان والد قراردادی که باید ایجاد شود عمل می کند. سپس یک عدد دلخواه ارائه شده توسط فرستنده (یا "salt") را اضافه می کند، که به توسعه دهنده اجازه می دهد تا همان کد را در آدرس های مختلف (با تغییر نمک) مستقر کند و از بازنویسی قراردادهای موجود و یکسان جلوگیری می کند. در نهایت، از هش keccak256 برخی بایت کد اولیه قرارداد هوشمند ("init") استفاده می کند، که دانه ای است که به یک قرارداد هوشمند جدید تبدیل می شود. این ترکیب هش شده یک آدرس اتریوم را تعیین می کند و سپس بایت کد داده شده را در آن آدرس مستقر می کند. تا زمانیکه بایت کد دقیقاً یکسان باقی می ماند، CREATE2 همیشه بایت کد داده شده را در همان آدرس در بلاک چین مستقر می کند.

در اینجا فرمول CREATE2 به نظر می رسد. (توجه: عنصر دیگری به نام "0xFF" را در مثال زیر مشاهده خواهید کرد. این فقط ثابتی است که CREATE2 از آن استفاده می کند جلوگیری از برخورد با اپکد CREATE قبلی.)

اکنون که راهی برای استقرار کد در یک آدرس قطعی داریم، چگونه ممکن است تغییر دادن کد در همان آدرس؟ در ابتدا ممکن است این امر غیرممکن به نظر برسد. اگر می خواهید کد جدیدی را با استفاده از CREATE2 مستقر کنید، بایت کد باید تغییر کند، و بنابراین، CREATE2 به آدرس دیگری مستقر می شود. اما اگر توسعه‌دهنده‌ای بایت کد را به گونه‌ای بسازد که بتواند در هنگام استقرار یک قرارداد هوشمند CREATE2 به کدهای مختلف تبدیل شود، چه؟

یک قرارداد دگرگونی در واقع چگونه کار می کند

دستور العمل تبدیل یک قرارداد هوشمند به یک قرارداد دگرگونی، در مجموع نیازمند سه قرارداد هوشمند است که هر کدام نقش منحصر به فردی را ایفا می کنند.

یکی از این اجزای ضروری کارخانه قرارداد دگرگونی، مغز عملیات است. این "کارخانه" مسئول استقرار قرارداد دگرگونی و همچنین قرارداد هوشمند دیگری به نام قرارداد پیاده سازی است که به این دلیل نامگذاری شده است که کد آن در نهایت در داخل قرارداد دگرگونی پیاده سازی می شود. یک رقص ظریف بین این سه قرارداد منجر به دگرگونی می شود، همانطور که در نمودار زیر نشان داده شده است.

بیایید هر مرحله، 1-7، را به تفصیل مورد بحث قرار دهیم تا عملیات در محل کار را روشن کنیم.

مرحله 1: یک توسعه دهنده همه چیز را به حرکت در می آورد

یک کدگذار مقداری کد قرارداد هوشمند - کد بایت قرارداد پیاده سازی - را طراحی می کند که در نهایت به قرارداد دگرگونی ختم می شود. توسعه دهنده این کد را به کارخانه قرارداد متامورفیک می فرستد، قراردادی هوشمند که هدف اصلی آن استقرار سایر قراردادهای هوشمند است. این عمل کل فرآیند ایجاد قرارداد دگرگونی را به حرکت در می آورد.

هر آنچه در ادامه می آید نتیجه این مرحله اولیه است. در واقع، مراحل 1 تا 6 در یک تراکنش اتمی روی بلاک چین اتفاق می‌افتد، یعنی تقریباً به یکباره. این مراحل را می توان بارها و بارها تکرار کرد، تا بی نهایت، برای جایگزینی کد در داخل قرارداد دگرگونی و حفظ آن به طور مستمر.

مرحله 2: کارخانه قرارداد پیاده سازی را مستقر می کند

اولین قراردادی که کارخانه مستقر می کند، قرارداد پیاده سازی است که حاوی کد پیاده سازی است. (خلاقانه، ما می دانیم.) قرارداد پیاده سازی را به عنوان یک اسکله بارگیری یا ایستگاه بین راهی در نظر بگیرید که قبل از ارسال به مقصد نهایی، که در این مورد، در داخل قرارداد دگرگونی خواهد بود، کدی را در خود نگه می دارد. 

مرحله 3: آدرس قرارداد اجرای فروشگاه های کارخانه

پس از استقرار آن در بلاک چین، قرارداد پیاده سازی لزوماً در برخی از آدرس های بلاک چین وجود خواهد داشت. Factory این آدرس قرارداد را در حافظه خود ذخیره می کند (تا بعداً در مرحله 5 استفاده شود). 

مرحله 4: کارخانه قرارداد دگرگونی را مستقر می کند

کارخانه قرارداد دگرگونی را با استفاده از CREATE2 و بایت کد دگرگونی مستقر می کند. شما می توانید یک راهنمای فنی و عمیق از نحوه عملکرد بایت کد دگرگونی پیدا کنید اینجا کلیک نمایید، اما کافی است بگوییم که وقتی بایت کد دگرگونی اجرا می شود، کد را از یک مکان زنجیره ای دیگر - در این مورد، از قرارداد پیاده سازی - در قرارداد دگرگونی کپی می کند. همانطور که در بخش گذشته در مورد آن صحبت کردیم، از آنجایی که CREATE2 قطعی است - تا زمانی که از همان فرستنده، نمک و کد بایت استفاده شود - پس آدرس قرارداد دگرگونی بدون توجه به اینکه این مراحل چند بار تکرار شوند ثابت می ماند.

در زیر نمونه ای از بایت کد دگرگونی به نظر می رسد مخزن دگرگونی با 0 سن این فقط یک نمونه از بایت کد دگرگونی است - تغییرات بالقوه بیشماری وجود دارد که تشخیص قراردادهای دگرگونی را بسیار پیچیده می کند.

مرحله 5: پرس و جوهای بایت کد دگرگونی آدرس قرارداد Factory for Implementation

بایت کد دگرگونی آدرس قرارداد پیاده سازی را از کارخانه می خواهد (همانطور که در مرحله 3 ذخیره شده است). تا زمانی که بایت کد دگرگونی که آدرس را درخواست می کند، تغییر کند، مهم نیست که آدرس قرارداد پیاده سازی تغییر کند. در واقع، اگر توسعه‌دهنده بعداً یک قرارداد پیاده‌سازی جدید - مانند قرارداد مخربی که برای سرقت توکن‌ها طراحی شده است - مستقر کند، لزوماً در یک آدرس بلاک چین متفاوت، در مرحله 2 مستقر می‌شود. این هیچ تأثیری بر ایجاد قرارداد دگرگونی ندارد.

مرحله 6: کد قرارداد پیاده سازی در قرارداد دگرگونی کپی می شود

با استفاده از آدرس بلاک چین که در مرحله 5 آموخته شد، بایت کد دگرگونی کد را در قرارداد پیاده‌سازی قرار می‌دهد و آن کد را در فضای ذخیره‌سازی محلی قرارداد دگرگونی کپی می‌کند. به این ترتیب شکل قرارداد دگرگونی تغییر می کند: با کپی کردن کد از قرارداد پیاده سازی. 

مرحله 7: آبکشی کنید و تکرار کنید

یک توسعه دهنده می تواند مراحل 1 تا 6 را بارها و بارها تکرار کند و کد موجود در قرارداد دگرگونی را با هر چیزی که دوست دارد از طریق یک قرارداد اجرایی جدید جایگزین کند. تنها چیزی که نیاز است استفاده از کدهای رمز خودکار SELFDESTRUCT - یا به عبارتی حیله گرانه تر، کدهای عملیاتی DELEGATECALL که در نهایت منجر به SELFDESTRUCT می شود - برای حذف کد از قبل موجود در قرارداد دگرگونی است. با تکرار چرخه با بایت کد جدید قرارداد پیاده سازی، قرارداد دگرگونی مانند جادو، شکل!

با استفاده از این تکنیک برای ایجاد قراردادهای دگرگونی، یک توسعه دهنده باهوش می تواند به طور مداوم زمین را زیر پای کاربران وب 3 جابجا کند. برای مثال، دوباره سناریوی کلاهبرداری را در نظر بگیرید. یک توسعه‌دهنده می‌تواند ابتدا قرارداد پیاده‌سازی را با کد توکن-staking اجرا کند که از طریق مسیر مداری نشان‌داده‌شده در گرافیک و توضیح داده‌شده در مراحل بالا، به قرارداد دگرگونی ختم می‌شود. کلاهبردار بعداً می‌تواند این کد را خود تخریب کرده و با استقرار یک قرارداد اجرایی جدید حاوی رمز جایگزین، آن را جایگزین کند.سرقت کد 

هر آنچه در قرارداد پیاده سازی مستقر شود در نهایت به قرارداد دگرگونی ختم می شود. این اصل ترفند است. 

***

قراردادهای هوشمند دگرگونی قرارداد اجتماعی ضمنی وب 3 را می شکند که آنچه می بینید همان چیزی است که به دست می آورید. مشابه روشی که بازی پوسته از سه فنجان متحرک برای پنهان کردن یک توپ استفاده می کند، تأثیر متقابل این سه قرارداد در ایجاد یک قرارداد دگرگونی، پیگیری عملکرد واقعی قرارداد را دشوار می کند. بازی پوسته‌ای مقایسه‌ای مناسب است، زیرا کلاهبرداران اعتماد به نفس اغلب برای اطمینان از برنده شدن، از سهل انگاری و هدایت اشتباه استفاده می‌کنند. در نسخه وب 3، نویسندگان قراردادهای دگرگونی می‌توانند به طور مشابه «توپ» - کد پیاده‌سازی، را ناپدید کنند (بخوانید: خود تخریبی)، و می‌توانند آن را با هر چیزی که دوست دارند جایگزین کنند.

وجود قراردادهای دگرگونی به این معنی است که کاربران web3 می توانند قراردادهایی را منعقد کنند که می توانند به دلخواه تغییر کنند - به همین دلیل درک و دفاع از این تهدید بسیار مهم است. آشکارساز قرارداد دگرگونی من تنها گام اول را به سوی شناسایی قراردادهای دگرگونی با تدبیری که به کار می برند ارائه می دهد. راه های مختلفی وجود دارد که آشکارساز را می توان در آینده بهبود بخشید. به عنوان مثال، با بررسی بازگشتی کارخانه (یا قرارداد توزیع کننده) که قرارداد دگرگونی را ایجاد کرده است، می توان دید که آیا کارخانه خود دگرگونی است یا خیر. این ویژگی می تواند یک افزودنی مفید برای نسخه ارتقا یافته 2 آشکارساز باشد.

شایان ذکر است یک بار دیگر: این ابزار آشکارساز ضد احمق نیست. پرچم هایی که می گیرد همه نشانه های گویای پتانسیل دگرگونی نیستند، اما سرنخ هایی را ارائه می دهند. شناسایی این پرچم ها فقط شروعی برای یک تحقیق دقیق تر است. به همین دلیل است که آشکارساز را برای جستجوی پرچم‌هایی گسترش دادیم که به راحتی می‌توانستند مثبت کاذب ایجاد کنند، مانند وجود کدهای باز CREATE2 یا DELEGATECALL. اگر پیشنهادی برای بهبود ابزار دارید یا می خواهید این کار اولیه را بسازید یا به آن اضافه کنید، با من در تماس باشید .

قراردادهای هوشمند را برای صفات دگرگونی تجزیه و تحلیل کنید با استفاده از ابزار Detector و بازدید کنید GitHub repo برای اطلاعات بیشتر

ویراستار: رابرت هکت @rhhackett

***

تشکر و قدردانی: می‌خواهم از رابرت هکت، ادی لازارین، سام راگزدیل، ریاز فیض‌الابهوی، نوح سیترون، میسون هال و پارک داجون برای بازخوردها و توصیه‌های ارزشمند در ایجاد این پست و ابزار تشکر کنم. 

***

نظرات بیان شده در اینجا نظرات پرسنل AH Capital Management, LLC ("a16z") نقل شده است و نظرات a16z یا شرکت های وابسته به آن نیست. برخی از اطلاعات موجود در اینجا از منابع شخص ثالث، از جمله از شرکت‌های سبد سرمایه‌ای که توسط a16z مدیریت می‌شوند، به‌دست آمده است. در حالی که a16z از منابعی گرفته شده است که معتقدند قابل اعتماد هستند، a16z به طور مستقل چنین اطلاعاتی را تأیید نکرده است و هیچ اظهارنظری در مورد صحت پایدار اطلاعات یا مناسب بودن آن برای یک موقعیت خاص ارائه نمی کند. علاوه بر این، این محتوا ممکن است شامل تبلیغات شخص ثالث باشد. aXNUMXz چنین تبلیغاتی را بررسی نکرده و محتوای تبلیغاتی موجود در آن را تایید نمی کند.

این محتوا فقط برای مقاصد اطلاعاتی ارائه شده است و نباید به عنوان مشاوره حقوقی، تجاری، سرمایه گذاری یا مالیاتی به آن اعتماد کرد. شما باید در مورد این موارد با مشاوران خود مشورت کنید. ارجاع به هر گونه اوراق بهادار یا دارایی دیجیتال فقط برای مقاصد توضیحی است و به منزله توصیه یا پیشنهاد سرمایه گذاری برای ارائه خدمات مشاوره سرمایه گذاری نیست. علاوه بر این، این محتوا برای هیچ سرمایه‌گذار یا سرمایه‌گذار بالقوه‌ای هدایت نشده و برای استفاده از آن در نظر گرفته نشده است، و تحت هیچ شرایطی نمی‌توان هنگام تصمیم‌گیری برای سرمایه‌گذاری در هر صندوقی که توسط a16z مدیریت می‌شود، به آن اعتماد کرد. (پیشنهاد سرمایه گذاری در یک صندوق a16z فقط توسط یادداشت قرار دادن خصوصی، قرارداد اشتراک و سایر اسناد مربوط به هر صندوق انجام می شود و باید به طور کامل خوانده شود.) هر گونه سرمایه گذاری یا شرکت پرتفوی ذکر شده، ارجاع شده، یا شرح داده شده نشان دهنده همه سرمایه گذاری ها در وسایل نقلیه تحت مدیریت a16z نیست، و نمی توان اطمینان داشت که سرمایه گذاری ها سودآور هستند یا سایر سرمایه گذاری های انجام شده در آینده ویژگی ها یا نتایج مشابهی خواهند داشت. فهرستی از سرمایه‌گذاری‌های انجام‌شده توسط صندوق‌های تحت مدیریت آندریسن هوروویتز (به استثنای سرمایه‌گذاری‌هایی که ناشر مجوز افشای عمومی a16z و همچنین سرمایه‌گذاری‌های اعلام‌نشده در دارایی‌های دیجیتالی عمومی را ارائه نکرده است) در https://a16z.com/investments موجود است. /.

نمودارها و نمودارهای ارائه شده در داخل صرفاً برای مقاصد اطلاعاتی هستند و هنگام تصمیم گیری برای سرمایه گذاری نباید به آنها اعتماد کرد. عملکرد گذشته نشان دهنده نتایج آینده نیست. محتوا فقط از تاریخ مشخص شده صحبت می کند. هر گونه پیش بینی، تخمین، پیش بینی، هدف، چشم انداز، و/یا نظرات بیان شده در این مطالب بدون اطلاع قبلی ممکن است تغییر کند و ممکن است متفاوت یا مغایر با نظرات بیان شده توسط دیگران باشد. لطفاً برای اطلاعات مهم بیشتر به https://a16z.com/disclosures مراجعه کنید.