Відсутність захисту конфіденційності є первородним гріхом усіх публічних блокчейнів – від оригінального документу про біткойни Сатоші до найсучаснішої, модульної та розпаралелізованої мережі, яка виконує 100 мільйонів транзакцій на секунду з цептосекундним часом завершення.

Взагалі кажучи, конфіденційність користувачів суперечить природі загальнодоступних блокчейнів: щоб публічна книга працювала, деякі дані транзакцій повинні надаватися спільно з вузлами та учасниками мережі. Ярлик для швидкого підключення цих систем до Інтернету полягає в тому, щоб просто зробити все загальнодоступним за замовчуванням.

Однак ця максимальна прозорість наражає користувачів на стеження, примус і непередбачені наслідки, як-от витік торгового сигналу. Це є комерційно нежиттєздатним і руйнує право визначати свою долю. Справжня самоохорона не може існувати, якщо користувачі не контролюють свої дані; конфіденційність полягає в тому, щоб відновити свободу користувачів вибирати, що вони роблять і не розкривати зовнішньому світу.

Ось сім фатальних недоліків, які часто зустрічаються в інструментах криптоконфіденційності:

Гріх 1 – Централізовані системи

У децентралізованому світі централізація є лінивець. Простіше (швидше та дешевше) запустити бухгалтерську книгу у внутрішній базі даних банку SQL, ніж надсилати транзакції навіть на найпродуктивніші блокчейни. 

Однак децентралізація означає стійкість. Саме тому криптовалюта має ринкову вартість. Без цього користувачам було б краще завдяки швидкості та економії коштів централізованих установ.

Це ще важливіше для протоколів конфіденційності, де централізація означає, що розробники надають собі привілейований доступ до даних користувачів.

Творці протоколу повинні ніколи надати собі ключі адміністратора, які можуть заморожувати або деанонімізувати користувачів. (RAILGUN використовує такі механізми, як Перегляд ключів щоб забезпечити недискримінаційну, контрольовану користувачем прозорість, де це необхідно.) 

Іншим вектором централізації є порогові мультипідписи, особливо для протоколів, які прагнуть обійти незахищені мости. Навіть якщо налаштовано «належним чином», мультипідпис 3 з 5, мабуть, гірший щодо довіри, ніж ваш сусідський банк.

І коли мультипідпис налаштовано неправильно….  

Гріх 2 – Жага лісозаготівлі

Інструменти конфіденційності повинні вживати всіх заходів, щоб не відслідковувати дії користувачів, зокрема особисті дані, такі як IP-адреси та дії веб-переглядача.

Протоколи конфіденційності повинні бути розроблені з урахуванням всеохоплюючої філософії, яка використовує лише миттєву відсутність розсудливості для деанонімізації користувачів.

Наприклад, Railway Wallet (який має інтегровану технологію конфіденційності RAILGUN) за замовчуванням проксі-виклики RPC для всіх користувачів, тому навіть якщо хтось не використовує VPN (а це має бути 🙁), його IP-адреса не просочується до вузлів RPC.

Гріх 3 – Зашифрований стан

Чому б не зробити всю систему приватною? Це спокусливо… але мати повністю зашифрований стан так само небажано, у певному сенсі, як і бути повністю публічним.

Стан шифрування створює чорну скриньку, де користувачі та спостерігачі не знають, що робить dApp. Він усуває найважливішу функцію безпеки блокчейнів: публічний контроль.

Якщо dApp є приватним, як перевірити, що економіка та актори діють правильно? Як правильно реагувати на експлойт або зловмисну ​​спробу, якщо ви не знаєте, чи щось сталося?

Конфіденційність користувачів хороша, як і прозорість протоколу.

Гріх 4 – Залежність від конкретних виробників

Бути «ненадійним» означає, що вам не потрібно довіряти третій стороні (тобто компанії, агенту або банківському касиру), щоб забезпечити роботу протоколу. Сильна сторона шифрування на основі нульових знань полягає в тому, що воно створює менше залежностей, зокрема від виробників.

Розглянемо, наприклад, якщо ви створюєте систему конфіденційності, яка покладається на розширення Software Guard Extensions, вбудовані компанією Intel у їхні процесори. Безпека вашої системи залежить від потенційної єдиної точки збою – віри в те, що Intel правильно реалізувала свій продукт.

Стимули Intel полягають у тому, щоб діяти належним чином, але покладання на SGX створює постійну вразливість і непотрібне припущення про довіру. Існують також міркування, пов’язані з підтримкою шлюзу за проектом, оскільки для SGX потрібне спеціальне обладнання, яке є відносно дорогим, незрозумілим і важким в обслуговуванні. Навпаки, валідатор підтвердження частки можна запустити на Raspberry Pi.

Гріх 5 – Шахрайство

Криптоконфіденційність є переконливим наративом, але це недостатньо сильна пропозиція, щоб виправдати створення абсолютно нового блокчейну або зведення (якщо тільки спеціальний ланцюжок не принесе суттєвих технічних інновацій).

Системи конфіденційності є найбільш ефективними, коли вони доступні в мережах, де існують користувачі та фінансова діяльність. На краще чи на гірше, Defi зібрався навколо Ethereum, EVM, а також кілька інших подібних середовищ Солана. Solidity — це король, і тому вона виграла від найбільших досліджень безпеки.

Створення нового середовища виконання та залучення розробників і користувачів потребує часу та часто нестабільних стимулів. Тим часом мільярди доларів уже зберігаються в публічних мережах, які відчайдушно потребують конфіденційності.

Спеціальні ланцюжки конфіденційності також створюють додаткові питання безпеки, наприклад, вимагають мостів, які знову і знову демонструють, що є найменш безпечним компонентом мереж блокчейну. Інші проблеми включають централізацію консенсусу, валідацію та секвенсори.

Гріх 6 – Складність будівельника

Розробників часто вважають геніями (і деякі такими є). Однак криптографія досить складна, тому примус розробників вивчати та використовувати власну мову, інструментарій або екосистему є надмірно складним і контрпродуктивним. 

Контракти, написані такими мовами, як Solidity або Vyper, можна переносити в мережі, що підтримують EVM. Це не стосується Rust та інших ланцюжків WebAssembly. Усі вони мають власні стандарти часу виконання. З точки зору конструктора, це означає, що для кожного ланцюжка потрібно підтримувати окремі кодові бази контрактів, незважаючи на те, що вони використовують ту саму мову.

В результаті продукт стає менш доступним.

Гріх 7 – незріла техніка

«Чарівні Інтернет-гроші» — справді чудовий мем. Однак розробники криптографії створюють фінансову технологію, яка має реальні наслідки та обробляє реальні гроші.

Технологія конфіденційності має подвійний обов’язок брати до уваги «реальність грошей» і саму «конфіденційність», тобто вона має бути захищена від фінансових зловживань ТА всього, що може деанонімізувати користувачів. Значна частина існуючих академічних досліджень технології існує не просто так.

Щоб ти не закінчив як IOTAперевіреною аксіомою є «ніколи не розгортайте свою криптографію».

Технології конфіденційності, зокрема, мають бути випробувані в боях і продумані, з широкими аудитами з боку охоронних фірм, оцінками від прихильників конфіденційності, перевіркою пера білими капелюхами тощо.

Інакше як можна очікувати, що люди – особливо очікувані нові звичайні користувачі – ризикуватимуть своєю ідентичністю та грошима на складній технологічній платформі?

Висновок

Публічні блокчейни є «докс-за-дизайном». Нелегко створити системи конфіденційності в ланцюжку, зберігаючи першочергові причини використання крипто, такі як можливість перевірки та децентралізація.

Чудовим ресурсом для оцінки рівнів конфіденційності вибраного інструменту конфіденційності є Конфіденційність Web3 Тепер ініціатива які класифікували та оцінили різні інструменти криптоконфіденційності. Перевірте це як чудовий перший крок до захисту вашої особистості в Інтернеті та ваших фінансів.

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://cryptoslate.com/the-seven-deadly-sins-of-crypto-privacy/