Чего боятся игроки DeFi больше всего? Отключения бирж, похищения доменов — такие случаи время от времени попадают в новости. Поэтому кто-то решил использовать Walrus Sites для хостинга фронтенда — загрузить HTML и JS-код в блокчейн, а затем через SuiNS его解析ировать, теоретически можно создать «вход, который никогда не закроется». Звучит довольно заманчиво.
Но всё не так просто. Обслуживание децентрализованного фронтенда гораздо сложнее, чем традиционной веб-страницы. Нужно не только заново загружать Blob-данные, но и обновлять указатели в цепочке. Это постоянная работа, и один раз всё не сделаешь.
Возникает вопрос: а что если команда разработчиков ленивая? Версия фронтенда отстает от итераций смарт-контрактов, и при каждом действии пользователя происходит сбой — такие случаи не редкость. Короче говоря, стабильность децентрализованного фронтенда в конечном итоге зависит от ответственности разработчиков.
Мой совет: использовать децентрализованный фронтенд как основной вход только в случае, если проект действительно гарантирует долгосрочное обслуживание, а код полностью открыт и проверяем. В противном случае, это скорее запасной вариант. В конце концов, эта технология всё ещё находится в стадии исследования, не стоит переоценивать её возможности.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
8
Репост
Поделиться
комментарий
0/400
PoolJumper
· 01-09 15:23
Децентрализованный фронтенд звучит круто, на самом деле это просто перенос проблем с бирж на разработчиков.
Посмотреть ОригиналОтветить0
governance_lurker
· 01-09 11:28
Говоря откровенно, всё по-старому: даже самая передовая технология не может противостоять человеческой лени.
Посмотреть ОригиналОтветить0
LiquiditySurfer
· 01-08 23:52
Ха, по сути, это просто преобразование централизованного риска в риск разработчика, интересно
---
Никогда не закроется? Разбег команды разработчиков — вот что вечно
---
Вот почему я все еще верю в глубину ликвидности, а не в децентрализованный фронтенд, серфинг — это дело стабильных волн
---
Атрибут запасного плана попадает в точку, большинство проектов просто не могут это поддерживать
---
Смарт-контракт обновляется мгновенно, фронтенд все еще спит, пользователи в кровь, эту схему видел уже много раз
---
Так что, в конце концов, вход в цепь должен опираться на репутацию, технология — это просто дымовая завеса
Посмотреть ОригиналОтветить0
NFTRegretDiary
· 01-08 23:37
Правильно, децентрализованный фронтенд звучит круто, но на самом деле всё зависит от честности. Если разработчик ленится, фронтенд сразу ломается.
Посмотреть ОригиналОтветить0
ForkMaster
· 01-08 23:36
Ответственность разработчика? Ха, за эти три года я видел не меньше "вечных обещаний", которые в итоге становились прощальными словами перед бегством. Децентрализованный фронтенд звучит красиво, но на практике это просто перенос проблем с централизованных систем на лень разработчиков, по сути ничего не изменилось.
Посмотреть ОригиналОтветить0
CryptoNomics
· 01-08 23:36
Честно говоря, вся эта идея "неизменяемого фронтенда" — это просто спектакль, пока разработчики действительно не возьмутся за графики обслуживания. Иначе математика не сходится.
Посмотреть ОригиналОтветить0
ZenZKPlayer
· 01-08 23:29
Опять хитрость, децентрализованный фронтенд в конце концов зависит от везения
Посмотреть ОригиналОтветить0
GateUser-bd883c58
· 01-08 23:25
Совершенно верно, децентрализованный фронтенд звучит круто, но в конечном итоге всё зависит от репутации человека.
Чего боятся игроки DeFi больше всего? Отключения бирж, похищения доменов — такие случаи время от времени попадают в новости. Поэтому кто-то решил использовать Walrus Sites для хостинга фронтенда — загрузить HTML и JS-код в блокчейн, а затем через SuiNS его解析ировать, теоретически можно создать «вход, который никогда не закроется». Звучит довольно заманчиво.
Но всё не так просто. Обслуживание децентрализованного фронтенда гораздо сложнее, чем традиционной веб-страницы. Нужно не только заново загружать Blob-данные, но и обновлять указатели в цепочке. Это постоянная работа, и один раз всё не сделаешь.
Возникает вопрос: а что если команда разработчиков ленивая? Версия фронтенда отстает от итераций смарт-контрактов, и при каждом действии пользователя происходит сбой — такие случаи не редкость. Короче говоря, стабильность децентрализованного фронтенда в конечном итоге зависит от ответственности разработчиков.
Мой совет: использовать децентрализованный фронтенд как основной вход только в случае, если проект действительно гарантирует долгосрочное обслуживание, а код полностью открыт и проверяем. В противном случае, это скорее запасной вариант. В конце концов, эта технология всё ещё находится в стадии исследования, не стоит переоценивать её возможности.