Невдовзі після активного набору популярності блокчейна Біткоін стало зрозуміло, що чим більша кількість людей його використовує - тим повільніше здійснюються транзакції. Можна було, звичайно, підвищити актуальність інформації за допомогою оплати вищої комісії, але це був удаваний вихід. Потрібно було щось змінювати на програмному рівні.
Справа в тому, що прискорити виробництво нових блоків було технічно неможливо - це справа займала мінімум 10 хвилин. Не можна було і збільшити розмір блоку - це вимагало б зміни всього протоколу. Але можна було пошукати інші шляхи.
І в 2015 році був впроваджений новий протокол Segregated Witness (SegWit), розроблений Пітером Віллом, спільно з іншими учасниками Bitcoin Core, який і повинен був вирішити проблему з масштабуванням, хоча б найближчим часом. Задумане вдалося і в серпні 2017 року це оновлення було реалізовано, привівши до одного з перших софтфорків в історії Біткоіна.
Переваги
- Збільшення пропускної здатності. Основна ідея протоколу SegWit полягала в тому, щоб розділити дані про транзакції і цифровий підпис, підвищивши, тим самим, кількість корисної інформації, що зберігається в блоці. Повністю відмовитися від цифрового підпису було нереально - він підтверджував наявність на рахунку відправника потрібної суми, але можна було реорганізувати його зберігання. Завдяки новому протоколу, вийшло мало не в 4 рази збільшити обсяг корисної інформації, що зберігається на блоці. І це без збільшення його реального розміру. Можна сказати, що тепер «практичний обсяг» блоків почав складати не 1 Мб, а 4 Мб.
- Підвищення швидкості транзакцій. Оскільки кожен новий блок вміщував в себе більше транзакцій, швидкість обробки інформації блокчейном значно збільшилася. Крім цього, скоротилися операційні витрати. І якщо раніше вони могли доходити до 30 доларів, то після впровадження SegWit - рідко перевищували 1$.
- Проблема пластичності транзакцій. Справа в тому, що підробити цифровий підпис набагато простіше, ніж дані про транзакції. І таке внесення змін призводило до псування цифрового ідентифікатора. А оскільки всі транзакції в мережі блокчейн незворотні - гроші просто блокувалися. Відділення цифрового підпису від прикладної інформації дозволило усунути цю проблему.
SegWit і Lightning Network
Завдяки рішенню проблеми пластичності транзакцій, з'явилася можливість створення протоколів другого рівня. Тобто тих, які працювали б поверх основних протоколів блокчейна, оптимізуючи деякі операції. Саме таким і є протокол Lightning Network. У його завдання входить збір великої кількості транзакцій за малий проміжок часу, проведення їх буферизації, а потім - відправка блоку цілком для проходження хешування.
Даний протокол другого рівня серйозно підвищив продуктивність мережі, довівши її швидкість до 7 транзакцій в секунду. Тому незабаром і інші блокчейни почали адаптувати Lightning Network під свої потреби. Особливо це було актуально для проектів, заснованих на програмному коді блокчейна біткоін.
SegWit і SegWit2x
Протокол SegWit спочатку планувався як «добровільний», а не примусовий. І ті, хто не поновив своє програмне забезпечення, могли продовжувати використовувати стару версію і досить ефективно майнити. Однак було і альтернативне рішення - SegWit2х.
Це оновлення несло в собі не тільки впровадження нових принципів зберігання інформації, але і збільшення розміру блоку до 2 Мб. Ось тільки більшість майнерів і користувачів тоді вважало, що це збільшить навантаження на машини і сповільнить процес роботи. І створить нерівноцінні умови для людей зі слабкими комп'ютерами. Так що консенсусу досягти не вийшло. А оскільки SegWit в принципі проблему вирішував, більш серйозні зміни було вирішено відкласти до інших часів.
Висновок
Впровадження нового протоколу серйозно підвищило ефективність роботи блокчейна біткоін. А той факт, що рішення про його прийняття здійснило децентралізоване співтовариство - зайвий раз підтвердив життєздатність подібних типів взаємодії.
Проте, не всі користувачі прийняли нові правила. Всього близько 53 відсотків перейшли на протокол SegWit, а решта працює «по-старому». Проте, поділу мережі не відбулося, оскільки заздалегідь було вирішено, що влаштовувати хардфорк поки що не потрібно. Втім, в майбутньому ситуація змінилася, оскільки навіть незважаючи на оптимізацію зберігання даних, місця в блоці було надто вже мало.