Один із викликів, з яким стикається Ethereum, полягає в тому, що за замовчуванням розширення та складність будь-якого блокчейн-протоколу з часом зростають. Це відбувається в двох аспектах:
Історичні дані: Усі транзакції, що здійснювалися в будь-який момент часу в історії, та всі створені облікові записи повинні бути постійно зберігатися всіма клієнтами та завантажуватися новими клієнтами, щоб повністю синхронізуватися з мережею. Це призведе до постійного збільшення навантаження на клієнтів та часу синхронізації з часом, навіть якщо ємність ланцюга залишається незмінною.
Функції протоколу: Додавання нових функцій значно легше, ніж видалення старих, що призводить до збільшення складності коду з часом.
Щоб Ethereum міг довгостроково існувати, нам потрібно застосувати потужний зворотний тиск на ці дві тенденції, з часом зменшуючи складність і розширення. Але в той же час, нам потрібно зберегти одну з ключових властивостей, яка робить блокчейн великим: тривалість. Ви можете помістити NFT, любовний лист у даних транзакції, або смарт-контракт на 1 мільйон доларів у ланцюг, увійти в печеру на десять років, і коли ви вийдете, виявите, що він все ще чекає на вас для читання та взаємодії. Щоб DApp могли повністю децентралізуватися і видалити ключі для оновлень, їм потрібно бути впевненими, що їх залежності не оновляться в руйнівний для них спосіб - особливо L1.
Якщо ми вирішимо знайти баланс між цими двома вимогами та максимально зменшити або повернути назад обтяженість, складність і занепад, зберігаючи при цьому безперервність, це абсолютно можливо. Біологічні організми можуть це зробити: хоча більшість організмів старіють з часом, деякі щасливчики цього не роблять. Навіть соціальні системи можуть мати дуже довге життя. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT в основному зник, вузли маяка вже зберігали старі дані до шести місяців. Знайти цей шлях для Ethereum більш загальним способом і рухатися до тривалого стабільного кінцевого результату — це ultimate challenge для довгострокової масштабованості Ethereum, технічної стійкості та навіть безпеки.
Знизити вимоги до зберігання клієнта, зменшуючи або усуваючи необхідність для кожного вузла постійно зберігати всю історію або навіть кінцевий стан.
Зниження складності протоколу шляхом усунення непотрібних функцій.
Історія закінчення терміну дії
Яку проблему вирішує?
Станом на момент написання цієї статті повністю синхронізований Ethereum-нод потребує приблизно 1,1 ТБ дискового простору для роботи клієнта, а також кілька сотень ГБ дискового простору для консенсус-клієнта. Більшу частину цього простору займає історія: дані про історичні блоки, транзакції та квитанції, більшість з яких існує вже багато років. Це означає, що навіть якщо обмеження Gas взагалі не збільшиться, розмір вузла буде продовжувати зростати на кілька сотень ГБ щороку.
Що це таке і як це працює?
Ключовою спрощеною характеристикою проблеми зберігання історії є те, що оскільки кожен блок за допомогою хеш-лінків (та інших структур) вказує на попередній блок, то для досягнення консенсусу щодо поточного стану достатньо досягти консенсусу щодо історії. Скільки б не було учасників, якщо мережа досягне консенсусу щодо останнього блоку, будь-який історичний блок, транзакція або стан (баланс рахунку, випадкове число, код, зберігання) можуть бути надані будь-яким учасником разом з Merkle-доказом, і цей доказ дозволяє будь-кому іншому перевірити його правильність. Консенсус є моделлю довіри N/2 з N, тоді як історія є моделлю довіри N з N.
Це надає нам багато варіантів для зберігання історичних записів. Одним із природних виборів є мережа, в якій кожен вузол зберігає лише невелику частину даних. Саме так працювали мережі-сіди протягом десятиліть: хоча мережа загалом зберігала та розповсюджувала мільйони файлів, кожен учасник зберігав та розповсюджував лише кілька з них. Можливо, на противагу інтуїції, цей підхід навіть не обов'язково знижує надійність даних. Якщо ми можемо побудувати мережу з 100,000 вузлів, де кожен вузол зберігає випадкові 10% історичних записів, тоді кожен запис буде скопійовано 10,000 разів – що повністю відповідає фактору копіювання в мережі з 10,000 вузлів, де кожен вузол зберігає все.
Сьогодні Ethereum починає позбуватися моделі, коли всі вузли постійно зберігають всю історію. Консенсусний блок (тобто частина, пов'язана з консенсусом на основі доказу частки) зберігає лише близько 6 місяців. Blob зберігається лише близько 18 днів. EIP-4444 має на меті ввести однорічний термін зберігання для історичних блоків та квитанцій. Довгостроковою метою є створення єдиного періоду (можливо, близько 18 днів), протягом якого кожен вузол відповідає за зберігання всього, а потім створення мережі рівноправних вузлів Ethereum, яка зберігатиме старі дані в розподіленому мережевому форматі.
Erasure codes можуть бути використані для підвищення надійності, одночасно зберігаючи той же коефіцієнт копіювання. Насправді, Blob вже використовує коди стирання для підтримки вибірки доступності даних. Найпростіше рішення, ймовірно, полягає в повторному використанні цих Erasure codes та розміщенні даних виконання та консенсусних блоків також у blob.
Розподілене зберігання та пошук об'єктів SSZ у Portal
Як підвищити ліміт gas (Paradigm)
ще потрібно зробити, що потрібно зважити?
Залишилася основна робота, яка включає в себе будівництво та інтеграцію конкретного розподіленого рішення для зберігання історії------принаймні, виконання історії, але зрештою також включає консенсус та blob. Найпростіше рішення - це (i) просте впровадження існуючої бібліотеки torrent, а також (ii), відоме як нативне рішення Ethereum мережі Portal. Як тільки ми впровадимо одне з них, ми можемо відкрити EIP-4444. EIP-4444 сам по собі не вимагає хард-форку, але дійсно потребує нової версії мережевого протоколу. Тому має сенс одночасно активувати його для всіх клієнтів, інакше існує ризик, що клієнт зазнає збою через підключення до інших вузлів, очікуючи завантажити повну історію, але фактично не отримуючи її.
Основні компроміси стосуються того, як ми намагаємося надати "древні" історичні дані. Найпростіше рішення — це завтра припинити зберігати древню історію та покластися на існуючі архівні вузли та різні централізовані постачальники для копіювання. Це легко, але це підриває позицію Ethereum як місця для постійних записів. Складніший, але безпечніший шлях — спочатку побудувати та інтегрувати торрент-мережу для розподіленого зберігання історії. Тут "наскільки ми старалися" має два виміри:
Як ми прагнемо забезпечити, щоб найбільший набір вузлів дійсно зберігав усі дані?
Наскільки глибоко ми інтегруємо історичні сховища в протокол?
Екстремальний параноїдальний підхід до (1) передбачає використання доказу застави: фактично вимагаючи, щоб кожен валідатор, що підтверджує права, зберіг певний відсоток історії та періодично шифрував перевіряв, чи вони це роблять. Більш м'який підхід полягає в встановленні добровільного стандарту для відсотка історії, що зберігається кожним клієнтом.
Щодо (2), базова реалізація лише стосується роботи, яка вже завершена сьогодні: Портал вже зберіг ERA файл, що містить всю історію Ethereum. Більш детальна реалізація передбачатиме фактичне підключення до процесу синхронізації, так що, якщо хтось захоче синхронізувати повну історію зберігання вузлів або архівних вузлів, навіть якщо інші архівні вузли не є онлайн, вони зможуть реалізувати це через пряму синхронізацію з мережі порталу.
Як це взаємодіє з іншими частинами дорожньої карти?
Якщо ми хочемо, щоб запуск або робота вузлів стали надзвичайно простими, то зменшення вимог до зберігання історії можна вважати більш важливим, ніж безстанність: з 1.1 ТБ, які потрібні вузлу, приблизно 300 ГБ є станом, а решта близько 800 ГБ стала історією. Лише реалізувавши безстанність та EIP-4444, можна досягти бачення запуску вузла Ethereum на смарт-годиннику, який можна налаштувати всього за кілька хвилин.
Обмеження зберігання історії також робить новіші вузли Ethereum більш життєздатними, оскільки вони підтримують лише найновіші версії протоколу, що спрощує їх. Наприклад, тепер можна безпечно видалити багато рядків коду, оскільки всі порожні слоти пам'яті, створені під час DoS-атаки 2016 року, були видалені. Оскільки перехід до доказу частки став історією, клієнти можуть безпечно видалити весь код, пов'язаний з доказом виконання.
Навіть якщо ми усунемо потребу в зберіганні історії на клієнті, потреба в зберіганні на клієнті продовжуватиме зростати приблизно на 50 ГБ на рік, оскільки стан продовжує зростати: залишки рахунків і випадкові числа, код контракту та зберігання контракту. Користувачі можуть сплатити одноразовий внесок, що назавжди накладе обтяження на теперішніх і майбутніх клієнтів Ethereum.
Стан виявляється більш складним для "закінчення терміну", ніж історія, оскільки EVM в основному спроектована на основі припущення, що як тільки об'єкт стану створено, він завжди буде існувати і його можна буде читати будь-якою транзакцією в будь-який час. Якщо ми введемо безстанність, деякі вважають, що ця проблема, можливо, не така вже й погана: лише спеціалізовані класи побудовників блоків повинні фактично зберігати стан, тоді як усі інші вузли (навіть ті, що містять генерацію списків!) можуть працювати без стану. Однак є точка зору, що ми не хочемо надто покладатися на безстанність, і в кінцевому підсумку ми можемо захотіти зробити стан недійсним, щоб підтримувати децентралізацію Ethereum.
Що це таке і як це працює
Сьогодні, коли ви створюєте новий об'єкт стану (це може статися одним із трьох способів: (i) надіславши ETH на новий рахунок, (ii) створивши новий рахунок за допомогою коду, (iii) налаштувавши раніше не торкнуті слоти зберігання), цей об'єкт стану залишатиметься в такому стані назавжди. Натомість ми хочемо, щоб об'єкт автоматично втрачав актуальність з часом. Ключовим викликом є досягти цього способом, що реалізує три цілі:
Ефективність: не потрібно великої кількості додаткових обчислень для запуску процесу закінчення терміну.
Зручність для користувача: якщо хтось зайде в печеру на п'ять років і повернеться, вони не повинні втратити доступ до позицій ETH, ERC20, NFT, CDP...
Дружелюбність до розробників: розробникам не потрібно переходити на абсолютно незнайому модель мислення. Крім того, вже застарілі та не оновлювані програми повинні продовжувати нормально працювати.
Не виконання цих цілей може призвести до легкого вирішення проблем. Наприклад, ви можете змусити кожен об'єкт стану також зберігати лічильник дати закінчення терміну (який можна продовжити, спаливши ЕТH, що може автоматично відбуватись під час читання або запису в будь-який момент), і мати цикл, який перебирає стан для видалення об'єктів стану з минулим терміном. Проте це впроваджує додаткові обчислення (навіть вимоги до зберігання), і це точно не може відповідати вимогам до зручності для користувачів. Розробникам також важко міркувати про крайні випадки, які включають скидання збережених значень до нуля. Якщо ви встановите таймер закінчення терміну в межах контракту, це технічно полегшить життя розробникам, але ускладнить економічну ситуацію: розробники повинні враховувати, як "перекласти" постійні витрати на зберігання на користувачів.
Це все проблеми, які основна розробницька спільнота Ethereum намагається вирішити протягом багатьох років, включаючи пропозиції "оренда блокчейну" та "відновлення". Врешті-решт, ми об'єднали найкращі частини пропозицій і зосередилися на двох категоріях "найменш поганих відомих рішень":
Часткове рішення для застарілого статусу
Рекомендації щодо терміну дії стану на основі циклів адрес.
Часткова давність стану
Деякі пропозиції про терміни закінчення дії дотримуються тих самих принципів. Ми розділяємо статуси на блоки. Кожен постійно зберігає "верхню мапу", де блоки можуть бути порожніми або непорожніми. Дані в кожному блоці зберігаються тільки якщо ці дані нещодавно відвідувалися. Існує механізм "відродження", якщо дані більше не зберігаються.
Основна різниця між цими пропозиціями полягає в тому, що: (i) як ми визначаємо "недавній", і (ii) я
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
15 лайків
Нагородити
15
6
Поділіться
Прокоментувати
0/400
OnchainGossiper
· 9год тому
Синхронізація клієнта така повільна, що хочеться блювати.
Переглянути оригіналвідповісти на0
MidnightSnapHunter
· 07-26 22:22
Віталік Бутерін нарешті збирається ліквідувати?
Переглянути оригіналвідповісти на0
PriceOracleFairy
· 07-24 21:24
не можу не погодитися, протокол блоату справжній... жахи масштабування не дають мені спати о 3 ранку, чесно кажучи
Переглянути оригіналвідповісти на0
WhaleWatcher
· 07-24 21:14
Віталік Бутерін, допоможи мені розрахувати витрати на зберігання.
Віталік говорить про The Purge: шлях довгострокової стійкості Ethereum
Віталік: можливе майбутнє Ethereum, The Purge
Один із викликів, з яким стикається Ethereum, полягає в тому, що за замовчуванням розширення та складність будь-якого блокчейн-протоколу з часом зростають. Це відбувається в двох аспектах:
Історичні дані: Усі транзакції, що здійснювалися в будь-який момент часу в історії, та всі створені облікові записи повинні бути постійно зберігатися всіма клієнтами та завантажуватися новими клієнтами, щоб повністю синхронізуватися з мережею. Це призведе до постійного збільшення навантаження на клієнтів та часу синхронізації з часом, навіть якщо ємність ланцюга залишається незмінною.
Функції протоколу: Додавання нових функцій значно легше, ніж видалення старих, що призводить до збільшення складності коду з часом.
Щоб Ethereum міг довгостроково існувати, нам потрібно застосувати потужний зворотний тиск на ці дві тенденції, з часом зменшуючи складність і розширення. Але в той же час, нам потрібно зберегти одну з ключових властивостей, яка робить блокчейн великим: тривалість. Ви можете помістити NFT, любовний лист у даних транзакції, або смарт-контракт на 1 мільйон доларів у ланцюг, увійти в печеру на десять років, і коли ви вийдете, виявите, що він все ще чекає на вас для читання та взаємодії. Щоб DApp могли повністю децентралізуватися і видалити ключі для оновлень, їм потрібно бути впевненими, що їх залежності не оновляться в руйнівний для них спосіб - особливо L1.
Якщо ми вирішимо знайти баланс між цими двома вимогами та максимально зменшити або повернути назад обтяженість, складність і занепад, зберігаючи при цьому безперервність, це абсолютно можливо. Біологічні організми можуть це зробити: хоча більшість організмів старіють з часом, деякі щасливчики цього не роблять. Навіть соціальні системи можуть мати дуже довге життя. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT в основному зник, вузли маяка вже зберігали старі дані до шести місяців. Знайти цей шлях для Ethereum більш загальним способом і рухатися до тривалого стабільного кінцевого результату — це ultimate challenge для довгострокової масштабованості Ethereum, технічної стійкості та навіть безпеки.
! Віталік: Можливе майбутнє для Ethereum, очищення
Очищення: основна мета
Знизити вимоги до зберігання клієнта, зменшуючи або усуваючи необхідність для кожного вузла постійно зберігати всю історію або навіть кінцевий стан.
Зниження складності протоколу шляхом усунення непотрібних функцій.
Історія закінчення терміну дії
Яку проблему вирішує?
Станом на момент написання цієї статті повністю синхронізований Ethereum-нод потребує приблизно 1,1 ТБ дискового простору для роботи клієнта, а також кілька сотень ГБ дискового простору для консенсус-клієнта. Більшу частину цього простору займає історія: дані про історичні блоки, транзакції та квитанції, більшість з яких існує вже багато років. Це означає, що навіть якщо обмеження Gas взагалі не збільшиться, розмір вузла буде продовжувати зростати на кілька сотень ГБ щороку.
Що це таке і як це працює?
Ключовою спрощеною характеристикою проблеми зберігання історії є те, що оскільки кожен блок за допомогою хеш-лінків (та інших структур) вказує на попередній блок, то для досягнення консенсусу щодо поточного стану достатньо досягти консенсусу щодо історії. Скільки б не було учасників, якщо мережа досягне консенсусу щодо останнього блоку, будь-який історичний блок, транзакція або стан (баланс рахунку, випадкове число, код, зберігання) можуть бути надані будь-яким учасником разом з Merkle-доказом, і цей доказ дозволяє будь-кому іншому перевірити його правильність. Консенсус є моделлю довіри N/2 з N, тоді як історія є моделлю довіри N з N.
Це надає нам багато варіантів для зберігання історичних записів. Одним із природних виборів є мережа, в якій кожен вузол зберігає лише невелику частину даних. Саме так працювали мережі-сіди протягом десятиліть: хоча мережа загалом зберігала та розповсюджувала мільйони файлів, кожен учасник зберігав та розповсюджував лише кілька з них. Можливо, на противагу інтуїції, цей підхід навіть не обов'язково знижує надійність даних. Якщо ми можемо побудувати мережу з 100,000 вузлів, де кожен вузол зберігає випадкові 10% історичних записів, тоді кожен запис буде скопійовано 10,000 разів – що повністю відповідає фактору копіювання в мережі з 10,000 вузлів, де кожен вузол зберігає все.
Сьогодні Ethereum починає позбуватися моделі, коли всі вузли постійно зберігають всю історію. Консенсусний блок (тобто частина, пов'язана з консенсусом на основі доказу частки) зберігає лише близько 6 місяців. Blob зберігається лише близько 18 днів. EIP-4444 має на меті ввести однорічний термін зберігання для історичних блоків та квитанцій. Довгостроковою метою є створення єдиного періоду (можливо, близько 18 днів), протягом якого кожен вузол відповідає за зберігання всього, а потім створення мережі рівноправних вузлів Ethereum, яка зберігатиме старі дані в розподіленому мережевому форматі.
Erasure codes можуть бути використані для підвищення надійності, одночасно зберігаючи той же коефіцієнт копіювання. Насправді, Blob вже використовує коди стирання для підтримки вибірки доступності даних. Найпростіше рішення, ймовірно, полягає в повторному використанні цих Erasure codes та розміщенні даних виконання та консенсусних блоків також у blob.
! Віталік: Можливе майбутнє Ethereum, Очищення
має якісь зв'язки з існуючими дослідженнями?
ще потрібно зробити, що потрібно зважити?
Залишилася основна робота, яка включає в себе будівництво та інтеграцію конкретного розподіленого рішення для зберігання історії------принаймні, виконання історії, але зрештою також включає консенсус та blob. Найпростіше рішення - це (i) просте впровадження існуючої бібліотеки torrent, а також (ii), відоме як нативне рішення Ethereum мережі Portal. Як тільки ми впровадимо одне з них, ми можемо відкрити EIP-4444. EIP-4444 сам по собі не вимагає хард-форку, але дійсно потребує нової версії мережевого протоколу. Тому має сенс одночасно активувати його для всіх клієнтів, інакше існує ризик, що клієнт зазнає збою через підключення до інших вузлів, очікуючи завантажити повну історію, але фактично не отримуючи її.
Основні компроміси стосуються того, як ми намагаємося надати "древні" історичні дані. Найпростіше рішення — це завтра припинити зберігати древню історію та покластися на існуючі архівні вузли та різні централізовані постачальники для копіювання. Це легко, але це підриває позицію Ethereum як місця для постійних записів. Складніший, але безпечніший шлях — спочатку побудувати та інтегрувати торрент-мережу для розподіленого зберігання історії. Тут "наскільки ми старалися" має два виміри:
Як ми прагнемо забезпечити, щоб найбільший набір вузлів дійсно зберігав усі дані?
Наскільки глибоко ми інтегруємо історичні сховища в протокол?
Екстремальний параноїдальний підхід до (1) передбачає використання доказу застави: фактично вимагаючи, щоб кожен валідатор, що підтверджує права, зберіг певний відсоток історії та періодично шифрував перевіряв, чи вони це роблять. Більш м'який підхід полягає в встановленні добровільного стандарту для відсотка історії, що зберігається кожним клієнтом.
Щодо (2), базова реалізація лише стосується роботи, яка вже завершена сьогодні: Портал вже зберіг ERA файл, що містить всю історію Ethereum. Більш детальна реалізація передбачатиме фактичне підключення до процесу синхронізації, так що, якщо хтось захоче синхронізувати повну історію зберігання вузлів або архівних вузлів, навіть якщо інші архівні вузли не є онлайн, вони зможуть реалізувати це через пряму синхронізацію з мережі порталу.
Як це взаємодіє з іншими частинами дорожньої карти?
Якщо ми хочемо, щоб запуск або робота вузлів стали надзвичайно простими, то зменшення вимог до зберігання історії можна вважати більш важливим, ніж безстанність: з 1.1 ТБ, які потрібні вузлу, приблизно 300 ГБ є станом, а решта близько 800 ГБ стала історією. Лише реалізувавши безстанність та EIP-4444, можна досягти бачення запуску вузла Ethereum на смарт-годиннику, який можна налаштувати всього за кілька хвилин.
Обмеження зберігання історії також робить новіші вузли Ethereum більш життєздатними, оскільки вони підтримують лише найновіші версії протоколу, що спрощує їх. Наприклад, тепер можна безпечно видалити багато рядків коду, оскільки всі порожні слоти пам'яті, створені під час DoS-атаки 2016 року, були видалені. Оскільки перехід до доказу частки став історією, клієнти можуть безпечно видалити весь код, пов'язаний з доказом виконання.
! Віталік: Можливе майбутнє Ethereum, The Purge
Закінчення терміну дії держави
Яку проблему вирішує?
Навіть якщо ми усунемо потребу в зберіганні історії на клієнті, потреба в зберіганні на клієнті продовжуватиме зростати приблизно на 50 ГБ на рік, оскільки стан продовжує зростати: залишки рахунків і випадкові числа, код контракту та зберігання контракту. Користувачі можуть сплатити одноразовий внесок, що назавжди накладе обтяження на теперішніх і майбутніх клієнтів Ethereum.
Стан виявляється більш складним для "закінчення терміну", ніж історія, оскільки EVM в основному спроектована на основі припущення, що як тільки об'єкт стану створено, він завжди буде існувати і його можна буде читати будь-якою транзакцією в будь-який час. Якщо ми введемо безстанність, деякі вважають, що ця проблема, можливо, не така вже й погана: лише спеціалізовані класи побудовників блоків повинні фактично зберігати стан, тоді як усі інші вузли (навіть ті, що містять генерацію списків!) можуть працювати без стану. Однак є точка зору, що ми не хочемо надто покладатися на безстанність, і в кінцевому підсумку ми можемо захотіти зробити стан недійсним, щоб підтримувати децентралізацію Ethereum.
Що це таке і як це працює
Сьогодні, коли ви створюєте новий об'єкт стану (це може статися одним із трьох способів: (i) надіславши ETH на новий рахунок, (ii) створивши новий рахунок за допомогою коду, (iii) налаштувавши раніше не торкнуті слоти зберігання), цей об'єкт стану залишатиметься в такому стані назавжди. Натомість ми хочемо, щоб об'єкт автоматично втрачав актуальність з часом. Ключовим викликом є досягти цього способом, що реалізує три цілі:
Ефективність: не потрібно великої кількості додаткових обчислень для запуску процесу закінчення терміну.
Зручність для користувача: якщо хтось зайде в печеру на п'ять років і повернеться, вони не повинні втратити доступ до позицій ETH, ERC20, NFT, CDP...
Дружелюбність до розробників: розробникам не потрібно переходити на абсолютно незнайому модель мислення. Крім того, вже застарілі та не оновлювані програми повинні продовжувати нормально працювати.
Не виконання цих цілей може призвести до легкого вирішення проблем. Наприклад, ви можете змусити кожен об'єкт стану також зберігати лічильник дати закінчення терміну (який можна продовжити, спаливши ЕТH, що може автоматично відбуватись під час читання або запису в будь-який момент), і мати цикл, який перебирає стан для видалення об'єктів стану з минулим терміном. Проте це впроваджує додаткові обчислення (навіть вимоги до зберігання), і це точно не може відповідати вимогам до зручності для користувачів. Розробникам також важко міркувати про крайні випадки, які включають скидання збережених значень до нуля. Якщо ви встановите таймер закінчення терміну в межах контракту, це технічно полегшить життя розробникам, але ускладнить економічну ситуацію: розробники повинні враховувати, як "перекласти" постійні витрати на зберігання на користувачів.
Це все проблеми, які основна розробницька спільнота Ethereum намагається вирішити протягом багатьох років, включаючи пропозиції "оренда блокчейну" та "відновлення". Врешті-решт, ми об'єднали найкращі частини пропозицій і зосередилися на двох категоріях "найменш поганих відомих рішень":
Часткова давність стану
Деякі пропозиції про терміни закінчення дії дотримуються тих самих принципів. Ми розділяємо статуси на блоки. Кожен постійно зберігає "верхню мапу", де блоки можуть бути порожніми або непорожніми. Дані в кожному блоці зберігаються тільки якщо ці дані нещодавно відвідувалися. Існує механізм "відродження", якщо дані більше не зберігаються.
Основна різниця між цими пропозиціями полягає в тому, що: (i) як ми визначаємо "недавній", і (ii) я