پایگاه خبری راه پرداخت دارای مجوز به شماره ۷۴۵۷۲ از وزارت فرهنگ و ارشاد اسلامی و بخشی از «شبکه عصر تراکنش» است. راه پرداخت فعالیت خود را از دوم اردیبهشت‌ماه ۱۳۹۰ شروع کرده و اکنون پرمخاطب‌ترین رسانه ایران در زمینه فناوری‌های مالی، بانکداری و پرداخت و استارت‌آپ‌های فین‌تک است.
چگونه zkTLS امکان انتقال داده‌های خصوصی در بلاکچین‌های عمومی را فراهم می‌آورد؟
حمید باطنی، توسعه‌دهنده نرم‌افزار و پروژه‌های بلاکچینی، در ارائه خود در چهارمین رویداد ۹ ژانویه درباره فناوری zkTLS و کاربردهای آن در بلاکچین و وب ۳.۰ و از اهمیت استفاده از پروتکل‌های امنیتی مانند TLS گفت. به گفته او، این پروتکل‌ها علاوه بر امنیت، قابلیت‌های اضافی مانند احراز هویت دیجیتال و تأیید وضعیت مالی را نیز فراهم می‌آورند. این قابلیت‌ها در کاربردهای مختلف از جمله قراردادهای هوشمند و بازارهای آنلاین می‌توانند به‌ویژه در کشورهایی مانند ایران تحول‌آفرین باشند.
او در بخش دیگری از ارائه خود به لزوم انتقال‌پذیری اعتبارها در سیستم‌های مختلف اشاره کرد و راه‌حل‌هایی را برای ساده‌تر کردن این فرایندها با استفاده از zkTLS پیشنهاد داد.
zkTLS و کاربردهای آن در وب ۳.۰
ZkTLS نوعی از تکنولوژی است که به ما اجازه اصالت‌سنجی داده‌های وب ۲.۰ در وب ۳.۰ را می‌دهد. ممکن است برخی از افراد فکر کنند که این کار را پیش‌ازاین هم اوراکل‌ها انجام داده‌اند، درحالی‌که اوراکل‌ها داده‌های وب ۲.۰ را به وب ۳.۰ منتقل می‌کنند. اما داده‌هایی که اوراکل‌ها معمولاً به وب ۳.۰ منتقل می‌کنند، داده‌های عمومی هستند که هر کسی می‌تواند از طریق اینترنت به آنها دسترسی پیدا کند. مثلاً اطلاعاتی مانند وضعیت آب و هوا یا نتایج بازی‌های فوتبال. اما ما درباره داده‌های خصوصی صحبت می‌کنیم. به‌عنوان‌مثال، ممکن است بخواهیم سن خود را تأیید کنیم که این اطلاعات نباید به‌راحتی در دسترس عموم قرار بگیرد. یا فرض کنید یک قرارداد هوشمند داریم که می‌خواهیم آن را محدود کنیم به افرادی که فقط از ایران هستند. این قرارداد هوشمند ممکن است در یک بلاکچین عمومی قرار گیرد، اما برای اینکه این داده‌ها مورداستفاده قرار گیرند، باید اطلاعاتی مانند شهروندی یا سن را تأیید کنیم که اوراکل‌ها نمی‌توانند به‌راحتی این کار را انجام دهند. برای این کار، به یک راهکار دیگر نیاز داریم که در اینجا به آن اشاره خواهیم کرد. قبل از شروع به توضیح درباره zkTLS، لازم است بررسی کنیم که چرا این تکنولوژی لازم است و چه مشکلی را حل می‌کند.
مشکلات کاربردهای بلاکچین
باوجود پیشرفت‌های چشمگیر در حوزه بلاکچین در چند سال اخیر، مانند تأیید ETFها، لایه‌های دوگانه اتریوم، هنوز یکی از اصلی‌ترین مشکلات بلاکچین این است که بسیاری از کاربردهای آن محدود به سفته‌بازی است. منظور از سفته‌بازی، دلالی و تعاریف منفی نیست. بسیاری از ما ارزهای دیجیتال را خریدوفروش می‌کنیم تا از تورم فرار کنیم، اما مشکل اینجاست که در بسیاری از موارد، کاربرد بلاکچین محدود به همین فعالیت‌ها می‌شود. دلیل این محدودیت هم این است که زندگی روزمره ما بیشتر بر پایه وب ۲.۰ است. ما غذا سفارش می‌دهیم، کارت به کارت می‌کنیم، فیلم می‌بینیم و بسیاری از فعالیت‌های روزانه‌مان را روی وب ۲.۰ انجام می‌دهیم. در حقیقت، داده‌های حساس ما مانند سن، محل سکونت، دانشگاه و ملیت بر روی وب ۲.۰ ذخیره می‌شوند، درحالی‌که این داده‌ها باید خصوصی باشند، نه عمومی. اگر بتوانیم اطمینان حاصل کنیم که مثلاً یک کارت به کارت انجام داده‌ایم، می‌توانیم این اطلاعات را به یک قرارداد هوشمند بیاوریم و بر اساس آن دارایی‌ها یا اطلاعات را آزاد کنیم. این همان چیزی است که RWA یا DEXها (صرافی‌های غیرمتمرکز) دنبال می‌کنند، اما محدودیت این صرافی‌ها این است که در فرایند ورود و خروج ارز فیات به مشکل می‌خورند. بنابراین، در اینجا نیاز به یک راه‌حل داریم که بتواند داده‌های خصوصی وب ۲.۰ را به طور امن و قابل استفاده در وب ۳.۰ منتقل کند.
زمانی که ما به یک وب‌سایت امن با پروتکل HTTPS متصل می‌شویم، در واقع فرآیند احراز هویت و رمزنگاری آغاز می‌شود و وب‌سایت ابتدا با استفاده از گواهی SSL/TLS مشخص می‌کند که آیا ارتباط امن است یا خیر. با بررسی این گواهی، مرورگر اطمینان می‌یابد که سایت موردنظر معتبر است و داده‌هایی که میان مرورگر و سرور منتقل می‌شود، رمزنگاری شده است. این بدین معناست که هیچ شخص دیگری نمی‌تواند به‌راحتی داده‌های حساس شما مانند شماره کارت‌بانکی یا رمز عبور را در طول انتقال، شنود کند.
اما چگونه این امنیت فراهم می‌شود؟ ابتدا، رمزنگاری نامتقارن (Public-Key Cryptography) بین مرورگر و سرور انجام می‌شود. در این مرحله، سرور یک کلید عمومی را ارسال می‌کند و مرورگر با استفاده از این کلید، داده‌ها را رمزنگاری می‌کند. سپس سرور با استفاده از کلید خصوصی خود، داده‌ها را بازگشایی می‌کند. پس از این مرحله، برای بهبود سرعت و کارایی، یک کلید سشن (Session Key) به طور موقت برای رمزنگاری داده‌ها ایجاد می‌شود که در آن، از رمزنگاری متقارن استفاده می‌شود. این به این معناست که هم مرورگر و هم سرور از یک کلید مشترک برای رمزنگاری و ارسال داده‌ها استفاده می‌کنند، به‌طوری‌که هیچ‌کدام نمی‌توانند به‌راحتی ادعا کنند که داده‌ها از سمت سرور آمده است اما این روش همچنان مشکل بزرگی دارد. ازآنجاکه هم مرورگر و هم سرور از یک کلید سشن برای رمزنگاری استفاده می‌کنند، احراز هویت به‌تنهایی کافی نیست.
به عبارت دیگر در این شرایط امکان دارن که فرد گیرنده از همان کلید استفاده کند و یک پیام دلخواه یا مخرب را امضا کند و ادعا کند این پیام از سمت سرور آمده است و به همین علت نمیتوانیم از TLS خالی به عنوان وسیله اعتبار سنجی استفاده کنیم و نیاز به تغییراتی در این فرایند داریم.
یکی از راه‌حل‌های پیشنهادی برای این مشکل، استفاده از فناوری‌هایی مانند MPC (Multi-Party Computation) است. با استفاده از این فناوری، عملیات رمزنگاری و امضا به چندین طرف مختلف سپرده می‌شود، به‌طوری که هیچ‌کدام از طرفین به‌تنهایی نمی‌توانند فرایند را دست‌کاری کنند. در این راستا، نهادهایی به نام «نوتری» وارد عمل می‌شوند که مسئولیت امضای داده‌ها را بر عهده می‌گیرند و به‌این‌ترتیب، دیگر نمی‌توان به‌راحتی مدعی شد که داده‌ها از سمت سرور آمده است.
مشکل جدیدی که ممکن است پیش آید، حریم خصوصی داده‌هاست. شاید شما نخواهید که نهاد نوتری به اطلاعات حساس شما مانند کد ملی یا شماره‌تلفن دسترسی پیدا کند. برای حل این مشکل، از Merkle Tree و فناوری‌هایی مانند Selective Disclosure استفاده می‌شود. با این روش، فقط بخش‌های ضروری از داده‌ها برای نهاد نوتری افشا می‌شود، به این معنی که فقط اطلاعات ضروری (مثلاً سن) در اختیار آن قرار می‌گیرد و بقیه اطلاعات خصوصی شما حفظ می‌شود. در نهایت، خروجی این فرایند، یک پیام امضا شده است که صحت داده‌ها را تأیید می‌کند. به‌عنوان‌مثال، اگر شما بخواهید سن خود را تأیید کنید، با استفاده از این فناوری‌ها و معماری‌ها، اطلاعات دقیق شما به نهادهای مربوطه ارسال می‌شود، ولی اطلاعاتی مانند کدملی یا سایر اطلاعات خصوصی فاش نخواهند شد. این تضمین می‌کند که سن شما به‌درستی تأیید می‌شود، اما هیچ‌کدام از اطلاعات دیگر شما در دسترس قرار نمی‌گیرد.
کانسپت zkTLS و کاربردهای آن
در پروتکل zkTLS ، وظیفه اصلی تضمین این است که اطلاعات ارسالی بین کاربر و سرور از لحاظ صحت و امنیت تأیید شود. این پروتکل به ما این اطمینان را می‌دهد که داده‌ها از منبع اصلی و مورد تأیید ارسال شده‌اند و هیچ‌گونه دست‌کاری در مسیر رخ نداده است. اما علاوه بر این، zkTLS قابلیت‌های اضافی نیز دارد که در کاربردهای خاص مفید است.
یکی از مهم‌ترین ویژگی‌های zkTLS ، پرتابلیتی داده‌ها یا همان Data Portability است. این ویژگی به این معناست که می‌توان گواهی‌های اطلاعاتی، مانند گواهی‌های احراز هویت، را به دیگر پلتفرم‌ها منتقل کرد. به‌عنوان‌مثال، می‌توانم گواهی تأیید هویت خود را از یک نهاد دولتی دریافت کنم و آن را به صرافی یا یک قرارداد هوشمند ارسال کنم تا اثبات کنم که هویت من معتبر است، بدون اینکه مجبور باشم اطلاعات شخصی خود را افشا کنم. کاربردهای رایج zkTLS به‌خصوص در احراز هویت و تأیید اعتبار شناخته می‌شود. برای مثال، در یک قرارداد هوشمند، می‌توانیم از گواهی تأیید هویت استفاده کنیم تا تنها شهروندان یک کشور خاص قادر به استفاده از آن قرارداد باشند. این امر امکان استفاده از قراردادهای هوشمند در بستر بلاکچین را با محدودیت‌های خاص جغرافیایی یا هویتی فراهم می‌کند.
علاوه بر احراز هویت، تأیید موجودی مالی یا Financial Verification یکی دیگر از کاربردهای جالب zkTLS است. فرض کنید که می‌خواهید در یک قرارداد هوشمند اثبات کنید که موجودی بانکی شما در یک بانک خاص به طور ثابت در ماه‌های گذشته بوده است. با استفاده از این پروتکل، می‌توانید به‌راحتی گواهی‌ای دریافت کنید که به شما اجازه می‌دهد بدون نیاز به مراجعه حضوری به بانک یا استفاده از API های بانکی، موجودی خود را در قرارداد هوشمند به اثبات برسانید.
همچنین در خریدوفروش بلیت کنسرت، با استفاده از یک قرارداد هوشمند و گواهی‌های zkTLS ، می‌توانیم یک تراکنش امن انجام دهیم که در آن هم خریدار و هم فروشنده از یک سیستم غیرمتمرکز بهره‌مند شوند. در این مدل، می‌توان از USDC به‌عنوان تضمینی برای معامله استفاده کرد و پس از اثبات انتقال بلیت، خریداری را تکمیل کرد. در این صورت، نیازی به اعتماد به شخص ثالث یا سیستم‌های مرکزی نیست. استفاده از zkTLS در ساخت جوامع خصوصی آنلاین online private communities نیز کاربرد دارد. در یک جامعه خصوصی، اعضا ممکن است هویت یکدیگر را ندانند، اما می‌توانند از طریق تأییدات معتبر به میزان اعتبار و توان مالی یکدیگر پی ببرند. به‌عنوان‌مثال، در یک گروه چت یا شبکه اجتماعی، افراد می‌توانند از طریق گواهی‌های zkTLS به یکدیگر ثابت کنند که دارایی معینی در یک صرافی خاص دارند، بدون اینکه نیاز به افشای اطلاعات محرمانه یا حساس باشد.
یکی از مهم‌ترین کاربردهای این تکنولوژی‌ها، احراز هویت دیجیتال است. ما می‌توانیم از یک سری APIها برای اتصال به سایت‌های دولتی استفاده کنیم و داده‌ها و گواهی‌های مربوطه را دریافت کنیم. این گواهی‌ها می‌توانند در کاربردهای مختلفی نظیر قراردادهای هوشمند در بلاکچین‌های عمومی به کار روند. به‌عنوان‌مثال، می‌توانیم قرارداد هوشمندی بسازیم که فقط به شهروندان یک کشور خاص اجازه استفاده از آن را بدهد. همچنین در شرایطی که لازم باشد ثابت کنم که مثلاً هر ماه میانگین خرید من از یک فروشگاه اینترنتی ثابت بوده است، می‌توانیم از این گواهی‌ها برای تأیید صحت داده‌ها استفاده کنیم.
یکی دیگر از کاربردهای جالب، تأیید وضعیت مالی است. برای مثال، فرض کنید که می‌خواهید ثابت کنید میانگین موجودی شما در یک بانک خاص ثابت بوده است. در اینجا دیگر نیازی به دریافت API از بانک یا درخواست گواهی فیزیکی نیست. فقط کافی است که به اینترنت بانک خود وارد شوید و گواهی را به دست آورده و در قرارداد هوشمند استفاده کنید. همچنین در زمینه مارکت پلیس‌ها (مثل خریدوفروش بلیت یا کالا)، می‌توان از این تکنولوژی‌ها استفاده کرد. به‌عنوان‌مثال، در یک پلتفرم مانند دیوار، مشکل اعتماد وجود دارد. طرفین نمی‌دانند آیا فروشنده بلیت کنسرت را به‌درستی ارسال خواهد کرد یا خیر. با استفاده از یک قرارداد هوشمند و یک API، خریدار می‌تواند یک مقدار USDC را قفل کند و پس از آنکه بلیت به ایمیلش منتقل شد، مبلغ را دریافت کند. این پروتکل امکان اعتماد بدون نیاز به ارتباطات مستقیم و اثبات بی‌واسطه را فراهم می‌کند.
با استفاده از این فناوری‌ها، می‌توانیم trustless Localbitcoins خلق کنیم، حتی برای ریال. برای متوقف کردن این سیستم‌ها، بانک مرکزی باید سیستم پرداخت‌های کارت به کارت را قطع کند. فرض کنید می‌خواهید یک کامیونیتی خصوصی ایجاد کنید یا یک گروه چت راه‌اندازی کنید. در این گروه، اعضا نمی‌دانند که با چه کسی صحبت می‌کنند، اما می‌دانند که فردی که در حال صحبت با آن‌هاست، از لحاظ مالی به سطح معینی رسیده و در یکی از صرافی‌های ایرانی فعالیت داشته است. این امکان فراهم می‌شود که بدون افشای هویت فرد، اطلاعات ضروری در دسترس قرار گیرد. با استفاده از یک API call می‌توانم ثابت کنم که من در فلان صرافی گردش مالی داشتم، بدون اینکه هویتم فاش شود یا نیازی به دادن رمز ورود به صرافی باشد تا فرد دیگری بتواند صحت ادعای من را تأیید کند. من می‌توانم این کار را خودم انجام دهم. حالا اگر دوست داشتید، می‌توانید از این اسلاید عکس بگیرید. این پروژه‌ها و زیرساخت‌ها و لایبرری‌هایی که در اختیار داریم، از جمله مهم‌ترین آنها TLS، Nose، Chainlink Decentralized Oracle هستند که می‌توانیم از آنها استفاده کنیم. همچنین لازم است اشاره کنم که این کانسپت به مرحله Production Level رسیده و حالا می‌توانیم محصولاتی مبتنی بر این تکنولوژی طراحی کنیم. اما این ایده چیزی جدید نیست؛ اولین‌بار در سال ۲۰۱۳ یکی از اعضای انجمن BitcoinTalk این موضوع را مطرح کرده بود و اکنون، پس از گذشت بیش از یک دهه، ما قادر به طراحی محصولات مبتنی بر این ایده هستیم.
پیشنهادهایی برای استفاده از zkTLS در سیستم‌های نظرسنجی و اعتبارسنجی
در بخش پایانی صحبت‌هایم قصد دارم به موضوعی اشاره کنم که به نظرم برای کشوری مانند ایران جالب است؛ اینکه با این تکنولوژی‌ها چه کسب‌وکارهایی می‌توانیم راه‌اندازی کنیم. واقعاً هرازگاهی فردی می‌گوید که کاش فلان چیز وجود داشت. اخیراً مهدی احمدی از رسانه آزاد با سهیل علوی در پادکست طبقه ۱۶ حضور داشت. در این پادکست، یکی از صحبت‌ها این بود که «ای‌کاش سیستم نظرسنجی‌ای داشتیم که مشخص نباشد افراد دقیقاً چه نظری دارند، اما مطمئن شویم که کسانی که رأی می‌دهند، ایرانی هستند و یک نفر فقط یک‌بار رأی می‌دهد». این چیزی است که می‌توان آن را با قرارداد هوشمند حل کرد. به این صورت که هر فرد به طور دیجیتال ثابت می‌کند که ایرانی است و مثلاً کارت ملی‌اش را وارد می‌کند و رأی خود را ثبت می‌کند. بدین ترتیب، هیچ‌کس نمی‌تواند هویت رأی‌دهنده را کشف کند، اما می‌تواند اطمینان حاصل کند که فرد، ایرانی است و تنها یک‌بار رأی داده است. بدین ترتیب، هیچ‌کس نمی‌تواند هویت رأی‌دهنده را کشف کند، اما می‌تواند اطمینان حاصل کند که فرد، ایرانی است و تنها یک‌بار رأی داده است.
نمونه‌ای دیگر، توییتی از ناصر حکیمی است. در این توییت او مطرح کرده بود که چرا اعتبارسنجی‌ها باید قابل‌جابه‌جایی باشند. منظور از این «قابل‌جابه‌جایی بودن» چیست؟ مثلاً فرض کنید که من به طور مداوم از اسنپ یا دیجی‌کالا استفاده کرده‌ام و از طرفی توانسته‌ام تمامی وام‌هایم را به‌موقع پرداخت کنم. آیا می‌توانم این اطلاعات را به‌صورت قابل‌انتقال از یک سیستم به سیستم دیگر داشته باشم؟ یک راهکار برای این موضوع این است که همه بانک‌ها و سرویس‌ها APIهایی فراهم کنند تا داده‌ها جمع‌آوری و اعتبارسنجی شوند و اعتبارها قابل‌جابه‌جایی باشند و یک راهکار zkTLS که به ما این امکان را می‌دهد که صحت‌سنجی داده‌ها را بدون نیاز به جمع‌آوری مستقیم داده‌ها از کاربران و بدون نیاز به گرفتن API از سرویس‌های مختلف انجام دهیم.
احتمالاً تا اینجای کار، بیشتر از اینکه مفهومی مشخص از این موضوعات به دست آورده باشید، احساس می‌کنید که این‌ها جادو و پیچیدگی‌های خاص خود را دارند و بسیاری از این مفاهیم هنوز برای شما سؤال است. اگر درباره zkTLS ایده‌ای دارید، می‌توانید با من در ارتباط باشید.
