Здається, це гарний час для швидкого нагадування про аудит безпеки та децентралізацію. Метою аудиту безпеки є аудит якості коду. Щоб переконатися у відсутності помилок реалізації, у правильності складання криптографії тощо. Аудит безпеки надзвичайно важливий, оскільки ДУЖЕ легко об'єднати найбезпечніші реалізації криптографії таким чином, що створює нові вразливості. Скажімо, ви сказали мені, що компанія Х найняла аудитора безпеки, і аудитор знайшов три середніх і два критичних бага, і всі вони були виправлені. Я не буду проводити його проти компанії Х. Пошук цих тонкощів – саме для цього і потрібні аудити. Однак аудит безпеки не має на меті підтвердити якість протоколу. За своєю конструкцією, вони не дають жодного уявлення про децентралізацію протоколу або припущення про довіру. Отже, хоча аудит важливий, якщо продукт є мережею, яка претендує на децентралізацію, він не замінює білу книгу, яка вирішує проблему моделі довіри та пояснює, чому очікується децентралізація. При цьому вкрай важливо, щоб компанія X (або, більш загально, будь-яка компанія, назва якої закінчується на X) випустила таку білу книгу перед запуском основної мережі. Я сподіваюся, що, якщо такий гіпотетичний сценарій буде реалізований, потенційні майбутні будівельники та користувачі знатимуть, що потрібно вимагати таку білу книгу від компанії X, і припускатимуть, що мережа до того часу буде централізованою. Зокрема, до тих пір, поки така біла книга не буде опублікована (або не буде надана якась еквівалентна резолюція моделі довіри), будь-який проект, ціннісна пропозиція якого спирається на децентралізацію, не повинен запускати послуги в цій мережі.