Багато хто прагне до максимальної швидкості, але цей підхід насправді зосереджений не на тому.
Де справжня проблема системи? Не у повільних обчисленнях, а у заторах між прийняттям рішення та виконанням, які нагадують паркінг. Кожен етап потребує проходження через перевірки, схвалення та очікування, і лише ці процеси можуть з’їсти всю пропускну здатність транзакції.
Оптимальне рішення — не додавати потужності, а усунути перешкоди. Вирізати непотрібні проміжні етапи, щоб команда безпосередньо доходила до рівня виконання. У такому разі, як може бути погана ліквідність? Чи може бути незручним інтерфейс?
Уявіть собі DeFi — якщо кожна транзакція потребує додаткової перевірки, витрати стануть непідйомними. Але як тільки ви оптимізуєте цей канал, ефективність всієї екосистеми зросте в рази. Саме тому деякі протоколи працюють дуже швидко — не тому, що їх обладнання краще, а тому, що архітектура розумніша.
Переміщення активів, підключення екосистем — ці операції мають бути максимально плавними. Коли нижній рівень не створює перешкод, верхні додатки можуть справді проявити свою силу.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
8
Репост
Поділіться
Прокоментувати
0/400
CommunitySlacker
· 14год тому
Правильно сказано, я вже скаржився на це: купа проектів все ще змагається за TPS, а користувацький досвід жахливий. Найбільш критичним є надмірність процесів, видалення тих марних етапів затвердження — ось справжній шлях до успіху.
Переглянути оригіналвідповісти на0
CodeSmellHunter
· 12-26 18:57
Згоден на всі 100%, я постійно скаржуся на цю проблему. Не всі повільності потребують швидшого CPU, іноді сама структура процесу є поганим дизайном.
Люди завжди думають, як прискорити, але не помічають, що купа зайвих перевірок може зруйнувати всю екосистему. Я бачив занадто багато проектів, що померли через архітектуру, справді.
На прикладі DeFi — хто спрощує проміжні етапи, той і виграє. Що може порівняти з апаратним забезпеченням? Всі приблизно однакові, важливо, щоб код був написаний розумно.
Якщо нижній рівень не забитий, тоді і вищий може летіти. З цим я погоджуюся.
Переглянути оригіналвідповісти на0
BottomMisser
· 12-26 18:56
Ви сказали чудово, насправді це питання архітектурного дизайну, а не просто складання апаратного забезпечення
Я давно це зрозумів, ті проєкти DeFi, які злетіли, — це тому, що вони різали процеси дуже жорстко
Саме так, багато разів вузьке місце — це ті зайві затвердження посередині, справді потрібно добре подумати
Цю точку зору я підтримую, погана ліквідність зовсім не через швидкість, а через затори
Здається, багато команд ще досі прагнуть до числа TPS, але насправді оптимізація маршрутизації — це ключовий шлях
Зняття перешкод > додавання потужності, ця логіка бездоганна
Переглянути оригіналвідповісти на0
LiquidityWitch
· 12-26 18:55
ngl вся ця одержимість "швидкістю" — це типу середній рівень інтелекту... справжня алхімія відбувається, коли ти позбавляєшся церемоніального баласту між наміром і виконанням. більшість протоколів — це просто процеси створення неефективності, маскуючись під безпеку lol
Переглянути оригіналвідповісти на0
ProposalDetective
· 12-26 18:49
Має рацію, вузьке місце зовсім не у обчислювальній потужності, а в тій купі процесів затримки. Я бачив, скільки проектів зазнали поразки на проміжних етапах, видалення процесів набагато надійніше, ніж додавання апаратного забезпечення.
Переглянути оригіналвідповісти на0
AlphaLeaker
· 12-26 18:45
Чорт, саме так, купа посередників справді є раковими раками. Саме так оптимізована наша платформа, і пропускна здатність транзакцій безпосередньо подвоюється після відключення резервної верифікації, що не є проблемою.
Переглянути оригіналвідповісти на0
DevChive
· 12-26 18:39
Немає нічого неправильного у цьому, мене просто дивує, чому ще так багато проектів зосереджуються лише на підвищенні TPS, а досвід користувачів залишається поганим. Справжнім вузьким місцем є ті зайві проміжні ланки, їх усунення дає миттєвий ефект.
Переглянути оригіналвідповісти на0
FOMOrektGuy
· 12-26 18:34
Чесно кажучи, більшість людей все ще змагаються за TPS, не усвідомлюючи, що вузьке місце давно змістилося
Зменшення процесів > нарощування апаратного забезпечення, тепер я це зрозумів
Підхід DeFi з надмірною перевіркою дійсно є великим витратником, я бачив занадто багато проектів, що загинули саме через це
Якщо нижній рівень не забитий, екосистема справді може розвиватися, у цьому немає сумніву
Багато хто прагне до максимальної швидкості, але цей підхід насправді зосереджений не на тому.
Де справжня проблема системи? Не у повільних обчисленнях, а у заторах між прийняттям рішення та виконанням, які нагадують паркінг. Кожен етап потребує проходження через перевірки, схвалення та очікування, і лише ці процеси можуть з’їсти всю пропускну здатність транзакції.
Оптимальне рішення — не додавати потужності, а усунути перешкоди. Вирізати непотрібні проміжні етапи, щоб команда безпосередньо доходила до рівня виконання. У такому разі, як може бути погана ліквідність? Чи може бути незручним інтерфейс?
Уявіть собі DeFi — якщо кожна транзакція потребує додаткової перевірки, витрати стануть непідйомними. Але як тільки ви оптимізуєте цей канал, ефективність всієї екосистеми зросте в рази. Саме тому деякі протоколи працюють дуже швидко — не тому, що їх обладнання краще, а тому, що архітектура розумніша.
Переміщення активів, підключення екосистем — ці операції мають бути максимально плавними. Коли нижній рівень не створює перешкод, верхні додатки можуть справді проявити свою силу.