قرارداد هوشمند؛ خطاهای فنی و مسئولیت حقوقی

قرارداد هوشمند؛ خطاهای فنی و مسئولیت حقوقی

از آسیب‌پذیری کد تا مسئولیت توسعه‌دهنده، بهره‌بردار و جبران خسارت

مقدمه؛ وقتی کد اجرا می‌شود، اما عدالت محقق نمی‌شود

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

اما خودکاربودن اجرا الزاماً به معنای درست‌بودن نتیجه نیست.

فرض کنیم یک قرارداد هوشمند برای پرداخت خسارت بیمه طراحی شده است. به دلیل خطای محاسباتی، به‌جای ۱۰ میلیون تومان، مبلغی ده برابر بیشتر پرداخت می‌شود. در سناریویی دیگر، قرارداد خرید صنعتی پس از دریافت اطلاعات اشتباه از سامانه حمل‌ونقل، وجه معامله را آزاد می‌کند؛ درحالی‌که کالا هنوز تحویل نشده است.

در هر دو مثال، نرم‌افزار ممکن است دقیقاً همان دستوراتی را اجرا کرده باشد که برنامه‌نویس نوشته است؛ اما نتیجه با توافق واقعی طرفین سازگار نیست.

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

برای پاسخ، باید سه مفهوم را از یکدیگر تفکیک کنیم: خطای فنی، نقض تعهد حقوقی و انتساب مسئولیت.

بخش اول: مبانی فنی و حقوقی

۱. قرارداد هوشمند چیست؟

قرارداد هوشمند برنامه‌ای است که بر بستر بلاکچین اجرا می‌شود و قواعد مشخصی را بر اساس وضعیت شبکه و ورودی‌های معتبر اعمال می‌کند.

۲. آیا هر قرارداد هوشمند یک قرارداد حقوقی است؟

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

۳. قرارداد هوشمند حقوقی چیست؟

Smart Legal Contract توافقی است که بخشی از تعهدات آن با استفاده از کد رایانه‌ای تعریف یا اجرا می‌شود و در نظام حقوقی قابل اعمال می‌تواند آثار الزام‌آور داشته باشد.

۴. تفاوت کد و توافق

کد بیانگر دستورهای قابل اجراست؛ توافق حقوقی بیانگر قصد طرفین، حقوق، تعهدات و آثار نقض آن‌هاست.

۵. اصل «کد قانون است» چیست؟

عبارت Code is Law برای توصیف نقش قواعد نرم‌افزاری در تنظیم رفتار دیجیتال به کار رفته است؛ اما به معنای برتری مطلق کد بر قوانین و حقوق اشخاص نیست.

۶. اجرای خودکار چه مزیتی دارد؟

می‌تواند هزینه پردازش، تأخیر و وابستگی به تصمیم‌گیری دستی را در برخی فرایندها کاهش دهد.

۷. اجرای خودکار چه خطری دارد؟

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

۸. تغییرناپذیری چیست؟

در بسیاری از شبکه‌های بلاکچینی، تغییر سوابق نهایی‌شده دشوار است؛ اما این ویژگی به معنای غیرممکن‌بودن اصلاح آثار حقوقی یا اجرای تراکنش جبرانی نیست.

۹. مسئولیت حقوقی چیست؟

مسئولیت حقوقی به الزام احتمالی شخص برای پاسخ‌گویی یا جبران زیان در شرایط مقرر قانونی یا قراردادی اشاره دارد.

۱۰. چرا تشخیص مسئول دشوار است؟

زیرا طراحی، توسعه، استقرار، مدیریت، تأمین داده و استفاده از قرارداد ممکن است میان چند شخص یا سازمان توزیع شده باشد.

بخش دوم: طبقه‌بندی خطاهای فنی

۱۱. خطای برنامه‌نویسی

اشتباه در پیاده‌سازی دستورها ممکن است موجب رفتار ناخواسته قرارداد شود.

۱۲. خطای منطق کسب‌وکار

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

۱۳. خطای کنترل دسترسی

کاربر یا نقش غیرمجاز ممکن است به عملیات حساس دسترسی پیدا کند.

۱۴. بازدرآمدی یا Reentrancy

قرارداد خارجی ممکن است پیش از تکمیل به‌روزرسانی وضعیت، مجدداً تابع آسیب‌پذیر را فراخوانی کند.

۱۵. خطای محاسباتی

اشتباه در اعشار، گردکردن یا تبدیل واحد می‌تواند مبلغ یا تعداد دارایی را نادرست محاسبه کند.

۱۶. سرریز و کم‌ریزی عددی

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

۱۷. اعتبارسنجی ناکافی ورودی

ورودی نامعتبر ممکن است موجب اجرای عملیات اشتباه شود.

۱۸. فراخوانی خارجی ناامن

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

۱۹. خطای اوراکل

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

۲۰. دست‌کاری قیمت

قراردادی که به قیمت لحظه‌ای قابل دست‌کاری متکی باشد ممکن است ارزش دارایی را نادرست محاسبه کند.

۲۱. حملات مبتنی بر وام آنی

Flash Loan می‌تواند قدرت مالی لازم برای بهره‌برداری از برخی ضعف‌های اقتصادی را در یک تراکنش فراهم کند.

۲۲. خطای ترتیب تراکنش

وابستگی نتیجه به ترتیب پردازش تراکنش‌ها ممکن است موجب رفتار نامطلوب شود.

۲۳. خطای زمان‌بندی

استفاده نامناسب از زمان یا فرض‌های نادرست درباره ترتیب رویدادها می‌تواند شرایط اجرا را مخدوش کند.

۲۴. خطای ارتقا

اشتباه در تغییر نسخه قرارداد می‌تواند منطق یا داده‌های ذخیره‌شده را مختل کند.

۲۵. خطای مقداردهی اولیه

ضعف در راه‌اندازی قرارداد یا پروکسی ممکن است امکان تصاحب اختیارات مدیریتی را فراهم کند.

۲۶. ضعف کلیدهای مدیریتی

سرقت یا سوءاستفاده از کلیدهای دارای اختیار بالا می‌تواند خسارت گسترده ایجاد کند.

۲۷. خطای اتصال سامانه‌ها

اشتباه در API، سامانه پرداخت یا نرم‌افزار سازمانی می‌تواند داده نادرست به قرارداد منتقل کند.

۲۸. خطای طراحی اقتصادی

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

بخش سوم: چگونه خطا به خسارت تبدیل می‌شود؟

۲۹. انتقال غیرمجاز دارایی

ضعف امنیتی ممکن است انتقال دارایی بدون اختیار معتبر را ممکن کند.

۳۰. پرداخت بیش از تعهد

خطای محاسباتی یا داده‌ای ممکن است مبلغ پرداخت را افزایش دهد.

۳۱. عدم پرداخت تعهد

ممکن است با وجود تحقق شرایط واقعی، قرارداد پرداخت را انجام ندهد.

۳۲. قفل‌شدن دارایی

دارایی ممکن است در قراردادی قرار گیرد که مسیر برداشت مؤثر ندارد.

۳۳. توقف خدمات

نقص نرم‌افزاری ممکن است دسترس‌پذیری یک خدمت حیاتی را مختل کند.

۳۴. از دست رفتن فرصت اقتصادی

تأخیر یا اجرای نادرست ممکن است موجب از دست رفتن معامله یا منفعت مورد انتظار شود.

۳۵. افشای اطلاعات

ثبت نادرست اطلاعات حساس روی بلاکچین ممکن است محرمانگی را نقض کند.

۳۶. خسارت به اشخاص ثالث

ممکن است افرادی که مستقیماً طرف قرارداد نیستند نیز متضرر شوند.

۳۷. خسارت زنجیره‌ای

وابستگی چند سامانه به یک قرارداد آسیب‌پذیر می‌تواند دامنه خسارت را گسترش دهد.

۳۸. مسئله اثبات خسارت

زیان‌دیده باید مطابق قانون قابل اعمال، عناصر لازم مانند زیان، رفتار قابل انتساب و رابطه سببیت را اثبات کند.

بخش چهارم: مسئولیت اشخاص و سازمان‌ها

۳۹. مسئولیت توسعه‌دهنده

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

۴۰. آیا هر باگ مسئولیت توسعه‌دهنده ایجاد می‌کند؟

خیر. وجود نقص فنی به‌تنهایی برای اثبات مسئولیت یک شخص کافی نیست.

۴۱. مسئولیت شرکت سفارش‌دهنده

شرکتی که سامانه را سفارش داده است ممکن است بر اساس نقش خود در طراحی الزامات، پذیرش محصول و بهره‌برداری مسئولیت داشته باشد.

۴۲. مسئولیت بهره‌بردار

بهره‌بردار ممکن است درباره مدیریت دسترسی، پایش، هشدار و واکنش به رخداد مسئول باشد.

۴۳. مسئولیت مدیر قرارداد

دارنده اختیارات مدیریتی ممکن است نسبت به سوءاستفاده از اختیار یا قصور در انجام تعهدات پاسخ‌گو باشد.

۴۴. مسئولیت تأمین‌کننده اوراکل

مسئولیت تأمین‌کننده داده به قرارداد خدمات، تعهدات پذیرفته‌شده و قواعد حقوقی قابل اعمال وابسته است.

۴۵. مسئولیت ممیز امنیتی

ممیز ممکن است در محدوده تعهد حرفه‌ای و قراردادی خود پاسخ‌گو باشد؛ اما گزارش ممیزی به معنای تضمین نبود هرگونه آسیب‌پذیری نیست.

۴۶. مسئولیت شرکت میزبان یا زیرساخت

در صورت وجود تعهد مشخص درباره دسترس‌پذیری یا امنیت، نقض آن می‌تواند آثار قراردادی داشته باشد.

۴۷. مسئولیت کاربران

کاربران نیز ممکن است بر اساس رفتار، تعهدات و میزان آگاهی خود مسئولیت‌هایی داشته باشند.

۴۸. مسئولیت اعضای DAO

عضویت در سازمان خودگردان غیرمتمرکز لزوماً مسئولیت شخصی ایجاد یا حذف نمی‌کند؛ وضعیت به ساختار حقوقی، نقش واقعی و قانون قابل اعمال بستگی دارد.

۴۹. مسئولیت چند شخص

ممکن است چند عامل در ایجاد خسارت نقش داشته باشند و نحوه تقسیم مسئولیت به قواعد حقوقی مربوط وابسته باشد.

۵۰. مسئولیت قراردادی

زمانی مطرح می‌شود که تعهد معتبر قراردادی نقض شده باشد و شرایط مطالبه ضمانت اجرا فراهم باشد.

۵۱. مسئولیت غیرقراردادی

در برخی شرایط، حتی بدون رابطه قراردادی مستقیم نیز امکان مطالبه خسارت وجود دارد.

۵۲. مسئولیت کیفری

در صورت تحقق عناصر قانونی جرم، رفتارهایی مانند دسترسی غیرمجاز یا تقلب ممکن است پیامد کیفری داشته باشند؛ صرف بروز خطای برنامه‌نویسی جرم محسوب نمی‌شود.

بخش پنجم: رابطه میان کد و متن حقوقی

۵۳. اگر متن قرارداد و کد متفاوت باشند چه می‌شود؟

پاسخ به مفاد توافق، نحوه ارجاع به کد و قانون قابل اعمال وابسته است.

۵۴. آیا می‌توان کد را بخشی از قرارداد دانست؟

بله، در برخی ساختارها طرفین می‌توانند به کد مشخص و نسخه معین آن ارجاع دهند.

۵۵. اهمیت تعیین نسخه

نسخه، هش و نشانی قرارداد باید به‌روشنی مشخص شوند.

۵۶. اولویت اسناد

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

۵۷. تعریف شرایط استثنایی

قطع اوراکل، خطای داده، حمله امنیتی و توقف شبکه باید پیش‌بینی شوند.

۵۸. تعریف رویداد نقض

باید روشن باشد چه رفتاری نقض تعهد محسوب می‌شود.

۵۹. تعریف خسارت

نوع زیان قابل مطالبه و روش ارزیابی آن باید در چارچوب قانون مشخص شود.

۶۰. محدودیت مسئولیت

بندهای محدودکننده مسئولیت ممکن است در بعضی نظام‌های حقوقی و برای بعضی رفتارها قابل اجرا نباشند.

۶۱. شرط حل اختلاف

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

۶۲. اجرای حکم

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

بخش ششم: اثبات خطا و رابطه سببیت

۶۳. گزارش تراکنش

هش تراکنش و سوابق بلاکچین می‌توانند شواهد فنی فراهم کنند.

۶۴. نسخه کد

کد منبع و بایت‌کد مستقرشده باید بررسی شوند.

۶۵. وضعیت قرارداد

داده‌های وضعیت در زمان رخداد اهمیت دارند.

۶۶. داده اوراکل

باید مشخص شود چه داده‌ای، از چه منبعی و در چه زمانی دریافت شده است.

۶۷. گزارش ممیزی

ممیزی‌های قبلی می‌توانند برای بررسی آگاهی از خطر و اقدامات انجام‌شده مفید باشند.

۶۸. سوابق تغییرات

تغییر نسخه، تنظیمات و نقش‌های مدیریتی باید مستند باشند.

۶۹. گزارش رخداد

خط زمانی رخداد و واکنش سازمان باید تهیه شود.

۷۰. بررسی رابطه سببیت

باید مشخص شود کدام رفتار یا نقص، چگونه به خسارت منجر شده است.

۷۱. بررسی عوامل دیگر

رفتار کاربر، حمله شخص ثالث و اختلال زیرساخت نیز ممکن است مؤثر باشند.

۷۲. کارشناسی فنی

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

بخش هفتم: نمونه‌های تاریخی و درس‌های حقوقی

۷۳. رخداد The DAO در سال ۲۰۱۶

بهره‌برداری از ضعف بازدرآمدی در The DAO از نمونه‌های تاریخی مهم امنیت قرارداد هوشمند است.

۷۴. درس The DAO

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

۷۵. رخدادهای کیف‌پول Parity

آسیب‌پذیری‌های مرتبط با منطق دسترسی و کتابخانه‌های مشترک نشان دادند وابستگی نرم‌افزاری می‌تواند پیامدهای گسترده داشته باشد.

۷۶. رخدادهای دست‌کاری اوراکل

اتکا به قیمت‌های قابل دست‌کاری می‌تواند به پرداخت یا تسویه نادرست منجر شود.

۷۷. حملات وام آنی

وام آنی ممکن است به‌عنوان ابزاری برای تشدید آسیب‌پذیری‌های دیگر استفاده شود؛ خود وام آنی لزوماً آسیب‌پذیری نیست.

۷۸. درس مشترک

ریشه خسارت همیشه در یک خط برنامه‌نویسی نیست؛ طراحی اقتصادی، حکمرانی و اعتماد به داده نیز اهمیت دارند.

بخش هشتم: مسئولیت در بیمه، سلامت و زنجیره تأمین

۷۹. بیمه پارامتریک

اگر داده بارندگی اشتباه باشد، باید مسئولیت منبع داده، بیمه‌گر و بهره‌بردار بر اساس تعهدات آن‌ها بررسی شود.

۸۰. پرداخت خسارت نادرست

پرداخت خودکار بیش از تعهد ممکن است مسئله استرداد وجه یا جبران زیان ایجاد کند.

۸۱. رد اشتباه خسارت

اگر قرارداد خسارت معتبر را نپردازد، بیمه‌گذار ممکن است بر اساس قرارداد و مقررات حق اعتراض داشته باشد.

۸۲. مدیریت رضایت بیمار

خطای کنترل دسترسی می‌تواند موجب نقض محرمانگی اطلاعات سلامت شود.

۸۳. دسترسی اضطراری

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

۸۴. تسویه مطالبات درمانی

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

۸۵. تأیید تحویل کالا

اگر اوراکل تحویل را به‌اشتباه تأیید کند، پرداخت ممکن است پیش از اجرای تعهد انجام شود.

۸۶. اختلاف کیفیت کالا

ثبت تحویل فیزیکی لزوماً به معنای تأیید کیفیت یا پذیرش نهایی نیست.

۸۷. تجهیزات پزشکی

ثبت خودکار کالیبراسیون یا خدمات نمی‌تواند جایگزین انجام واقعی آزمون یا تعمیر شود.

۸۸. نتیجه کاربردی

در صنایع حساس، تفکیک میان «ثبت رویداد»، «تأیید تخصصی» و «اجرای تعهد مالی» ضروری است.

بخش نهم: الزامات حقوقی در ایران

۸۹. قانون مدنی

قواعد عمومی قراردادها، تعهدات و جبران خسارت از مبانی مهم بررسی روابط قراردادی هستند.

۹۰. قانون تجارت الکترونیکی

مقررات مربوط به داده‌پیام، امضای الکترونیکی و برخی آثار حقوقی مبادلات الکترونیکی می‌توانند مرتبط باشند.

۹۱. قانون مسئولیت مدنی

در شرایط مقرر، می‌تواند مبنایی برای بررسی مسئولیت ناشی از ورود زیان باشد.

۹۲. قانون جرایم رایانه‌ای

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

۹۳. مقررات بخشی

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

۹۴. شناسایی طرف قرارداد

باید مشخص باشد چه شخص حقیقی یا حقوقی تعهدات را پذیرفته است.

۹۵. اثبات رضایت

صرف اتصال کیف‌پول یا ارسال تراکنش همیشه برای اثبات آگاهی و رضایت معتبر نسبت به تمام شروط کافی نیست.

۹۶. قابلیت استناد داده

اعتبار و ارزش اثباتی سوابق دیجیتال باید در چارچوب قانون و شرایط نگهداری بررسی شود.

۹۷. تعیین مرجع اختلاف

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

۹۸. ضرورت بررسی موردی

نباید فرض کرد تمام قراردادهای هوشمند در ایران خودبه‌خود معتبر یا نامعتبر هستند؛ موضوع و ساختار هر پروژه باید جداگانه بررسی شود.

بخش دهم: پیشگیری فنی و حکمرانی ریسک

۹۹. تحلیل تهدید

دارایی‌ها، اختیارات، نقاط شکست و مهاجمان احتمالی شناسایی شوند.

۱۰۰. طراحی امن

کنترل دسترسی، حداقل اختیار و جداسازی مسئولیت‌ها از ابتدا لحاظ شوند.

۱۰۱. آزمون واحد

توابع و شرایط مرزی آزمایش شوند.

۱۰۲. آزمون یکپارچگی

ارتباط قرارداد با اوراکل، توکن و سامانه بیرونی بررسی شود.

۱۰۳. آزمون فازینگ

ورودی‌های متنوع و غیرمنتظره برای کشف رفتارهای ناخواسته استفاده شوند.

۱۰۴. آزمون مبتنی بر ناوردا

قواعدی که همیشه باید برقرار بمانند، مانند حفظ مجموع دارایی‌ها، به‌صورت خودکار بررسی شوند.

۱۰۵. ممیزی مستقل

پیش از استقرار و پس از تغییرات مهم، ارزیابی مستقل انجام شود.

۱۰۶. تأیید رسمی

در کاربردهای حساس، روش‌های Formal Verification می‌توانند برای بررسی برخی ویژگی‌های مشخص استفاده شوند.

۱۰۷. چندامضایی

اختیارات مدیریتی حساس می‌توانند با سازوکار چندامضایی کنترل شوند.

۱۰۸. تأخیر زمانی

Timelock می‌تواند برای تغییرات مهم، فرصت مشاهده و واکنش ایجاد کند.

۱۰۹. توقف اضطراری

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

۱۱۰. پایش لحظه‌ای

تراکنش‌ها و رویدادهای غیرعادی باید پایش شوند.

۱۱۱. برنامه پاسخ به رخداد

مسئولان، مسیر ارتباطی، حفظ شواهد و اقدامات اضطراری مشخص شوند.

۱۱۲. مستندسازی

تصمیم‌های طراحی، نتایج آزمون و محدودیت‌های شناخته‌شده ثبت شوند.

بخش یازدهم: چارچوب قراردادی پیشنهادی برای پروژه‌ها

۱۱۳. تعریف دقیق موضوع

مشخص شود قرارداد هوشمند چه عملیاتی را انجام می‌دهد و چه عملیاتی خارج از دامنه آن است.

۱۱۴. تعیین نسخه فنی

نشانی، شبکه، نسخه و هش کد در پیوست فنی درج شود.

۱۱۵. تعیین مسئول توسعه

تعهدات توسعه‌دهنده درباره کیفیت و رفع نقص مشخص شود.

۱۱۶. تعیین مسئول بهره‌برداری

پایش، مدیریت کلیدها و پاسخ به رخداد به مسئول معین سپرده شود.

۱۱۷. تعیین مسئول داده

منبع داده، سطح خدمت و سازوکار رسیدگی به خطا تعریف شود.

۱۱۸. تعیین حدود ممیزی

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

۱۱۹. پذیرش ریسک

خطرات شناخته‌شده با زبان قابل فهم به طرفین اعلام شوند.

۱۲۰. تعیین سازوکار توقف

شرایط و اختیار توقف اضطراری مشخص شوند.

۱۲۱. تعیین فرایند اصلاح

نحوه تغییر نسخه و تصویب ارتقا تعریف شود.

۱۲۲. تعیین نحوه جبران

مسیر رسیدگی به خسارت و اجرای تصمیم معتبر مشخص شود.

۱۲۳. تعیین مرجع اختلاف

قانون حاکم و مرجع رسیدگی در حدود مجاز تعیین شوند.

۱۲۴. تعیین خروج از خدمت

تکلیف داده‌ها، دارایی‌ها و تعهدات هنگام توقف سامانه روشن شود.

بخش دوازدهم: پرسش‌های متداول

۱۲۵. اگر قرارداد هوشمند هک شود چه کسی مسئول است؟

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

۱۲۶. آیا توسعه‌دهنده همیشه مسئول است؟

خیر. مسئولیت نیازمند مبنای حقوقی و احراز شرایط مربوط است.

۱۲۷. آیا گزارش ممیزی مسئولیت را حذف می‌کند؟

خیر. ممیزی یک ابزار کاهش ریسک است، نه تضمین مطلق امنیت.

۱۲۸. آیا کد اشتباه می‌تواند قرارداد معتبر را نقض کند؟

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

۱۲۹. آیا تراکنش بلاکچینی قابل بازگشت است؟

تراکنش نهایی‌شده معمولاً با دستور یک‌جانبه قابل حذف نیست، اما ممکن است با انتقال جبرانی یا راهکار حقوقی آثار آن جبران شود.

۱۳۰. آیا مسئولیت اوراکل قابل مطالبه است؟

در شرایطی که مبنای قراردادی یا قانونی وجود داشته باشد، ممکن است.

۱۳۱. آیا استفاده از نرم‌افزار متن‌باز مسئولیت را از بین می‌برد؟

خیر. متن‌بازبودن به‌تنهایی پاسخ قطعی درباره مسئولیت ایجاد نمی‌کند.

۱۳۲. آیا DAO می‌تواند مسئولیت حقوقی داشته باشد؟

بسته به ساختار و قانون قابل اعمال، ممکن است مسئولیت متوجه شخصیت حقوقی یا اشخاص مرتبط شود.

۱۳۳. آیا می‌توان قرارداد هوشمند را بیمه کرد؟

در برخی بازارها محصولات پوشش ریسک قرارداد هوشمند وجود دارند، اما دامنه و استثناهای پوشش باید بررسی شوند.

۱۳۴. آیا خطای اوراکل با ممیزی کد کشف می‌شود؟

ممیزی ممکن است ضعف اعتبارسنجی داده را شناسایی کند، اما صحت همه داده‌های آینده را تضمین نمی‌کند.

۱۳۵. آیا مسئولیت کیفری با خطای فنی یکسان است؟

خیر. مسئولیت کیفری به تحقق عناصر قانونی جرم وابسته است.

۱۳۶. آیا توافق طرفین می‌تواند همه مسئولیت‌ها را حذف کند؟

خیر. اعتبار شروط محدودکننده مسئولیت به قانون قابل اعمال و نوع رفتار بستگی دارد.

۱۳۷. آیا قرارداد هوشمند برای خدمات درمانی مناسب است؟

برای برخی فرایندهای اداری و مجوزها ممکن است مناسب باشد، اما تصمیم‌های حساس بالینی نیازمند کنترل‌های ویژه هستند.

۱۳۸. مهم‌ترین اقدام پیش از استقرار چیست؟

ترکیب تحلیل حقوقی، طراحی امن، آزمون جامع و ممیزی مستقل.

۱۳۹. مهم‌ترین اقدام پس از استقرار چیست؟

پایش مستمر، مدیریت اختیارات و آمادگی پاسخ به رخداد.

۱۴۰. اصل راهبردی چیست؟

اجرای خودکار نباید به معنای حذف پاسخ‌گویی انسانی و سازمانی باشد.

جمع‌بندی؛ مسئولیت را نمی‌توان به کد واگذار کرد

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

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

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

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

قرارداد هوشمند می‌تواند اجرای تعهد را خودکار کند؛ اما نمی‌تواند مسئولیت حقوقی و ضرورت عدالت قراردادی را حذف کند.

منابع تخصصی

۱. OWASP Smart Contract Top 10 — https://scs.owasp.org/sctop10/

۲. Ethereum Smart Contract Security — https://ethereum.org/developers/docs/smart-contracts/security/

۳. OpenZeppelin Contracts — https://docs.openzeppelin.com/contracts/

۴. OWASP Smart Contract Security Verification Standard — https://scs.owasp.org/

۵. UK Law Commission — Smart Contracts — https://lawcom.gov.uk/project/smart-contracts/

۶. NIST Blockchain Technology Overview — https://doi.org/10.6028/NIST.IR.8202

۷. Solidity Security Considerations — https://docs.soliditylang.org/en/latest/security-considerations.html

۸. قانون مدنی ایران، قانون مسئولیت مدنی، قانون تجارت الکترونیکی و قانون جرایم رایانه‌ای؛ بررسی متن معتبر و اصلاحات لازم در هر پرونده ضروری است.

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