Багато людей, побачивши, що певний провідний протокол приватності підтримує порогове шифрування та захист даних приватності, автоматично вважають його абсолютним сейфом і прагнуть зберігати там усю конфіденційну інформацію. Чесно кажучи, ця ідея дуже небезпечна і трохи лінива.
Ключове питання тут: хоча вузли дійсно не бачать дані, які ви зберігаєте у фрагментах, вся система доступу повністю залежить від правил смарт-контрактів, які ви написали у мережі Sui. Іншими словами, безпека — це ваша відповідальність.
Чи є у вашому коді контракту вразливості? Чи був приватний ключ управління доступом неправильно збережений і злитий? Тоді "замок" у мережі фактично стає беззмістовним. Програмована приватність звучить дуже просунуте, але по суті, рівень безпеки протоколу визначається якістю вашого коду, а не самим дизайном протоколу.
Тому, щоб зберегти ключові дані, потрібно пройти повний аудит і чітко закодувати правила доступу. Для тих, хто не має можливості писати безпечні контракти, необдумане використання системи програмованої приватності може бути навіть ризикованішим, ніж традиційне централізоване зберігання. Це потрібно усвідомлювати.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
6 лайків
Нагородити
6
6
Репост
Поділіться
Прокоментувати
0/400
FrontRunFighter
· 2год тому
ngl, це саме тут більшість розробників потрапляють у серйозні проблеми. вони бачать "порогове шифрування" і думають, що це якась магічна паличка, але насправді ви просто переносите зону атаки на свій погано перевірений код. протокол не ваш охоронець—*ви*.
Переглянути оригіналвідповісти на0
DataOnlooker
· 01-08 23:51
Це дуже правильно, скільки людей було обдурено цими словами, справді вважаючи, що угода про конфіденційність — це незламний щит
Переглянути оригіналвідповісти на0
RugDocDetective
· 01-08 23:49
По суті, якщо ваш код не працює — не звинувачуйте протокол
Переглянути оригіналвідповісти на0
BearMarketBard
· 01-08 23:27
Кажучи прямо, поганий код контракту не варто звинувачувати у протоколі
Переглянути оригіналвідповісти на0
OneBlockAtATime
· 01-08 23:23
Зовсім правильно, це поширена хвороба більшості людей — побачивши нову концепцію, хочуть поставити все на карту. Я бачив кілька проектних команд, які керували приватними ключами так хаотично, що потім звинувачували протокол у несправності.
Переглянути оригіналвідповісти на0
ProbablyNothing
· 01-08 23:23
Га-га, справді, скільки людей просто шукають новизни, код настільки поганий, що його навіть не соромно напихати даними, заслужено отримати по зубах
Багато людей, побачивши, що певний провідний протокол приватності підтримує порогове шифрування та захист даних приватності, автоматично вважають його абсолютним сейфом і прагнуть зберігати там усю конфіденційну інформацію. Чесно кажучи, ця ідея дуже небезпечна і трохи лінива.
Ключове питання тут: хоча вузли дійсно не бачать дані, які ви зберігаєте у фрагментах, вся система доступу повністю залежить від правил смарт-контрактів, які ви написали у мережі Sui. Іншими словами, безпека — це ваша відповідальність.
Чи є у вашому коді контракту вразливості? Чи був приватний ключ управління доступом неправильно збережений і злитий? Тоді "замок" у мережі фактично стає беззмістовним. Програмована приватність звучить дуже просунуте, але по суті, рівень безпеки протоколу визначається якістю вашого коду, а не самим дизайном протоколу.
Тому, щоб зберегти ключові дані, потрібно пройти повний аудит і чітко закодувати правила доступу. Для тих, хто не має можливості писати безпечні контракти, необдумане використання системи програмованої приватності може бути навіть ризикованішим, ніж традиційне централізоване зберігання. Це потрібно усвідомлювати.