Переосмислення потенціалу децентралізації сервісів доступу до доменів

Нещодавній інцидент спонукав мене до повторного розгляду традиційних послуг доступу до доменних імен. Ми завжди вважали, що стабільні та надійні служби DNS можуть мати проблеми, і це змусило мене задуматися, чи може децентралізація стати вартою дослідження альтернативою.

На блокчейні розгортання веб-сторінок може мати кілька переваг:

1. Децентралізація: всі зміни потребують консенсусу для виконання, немає єдиного органу, який може діяти одноосібно.

2. Не потрібно сертифікатів: блокчейн сам по собі використовує криптографічні технології, додаткові сертифікати не потрібні.

Я раніше дізнавався про доменну схему на TON, тоді вважав, що це може бути лише цікавим, але не дуже практичним випробуванням, адже традиційні способи доступу вже досить стабільні та поширені. Але тепер, згадуючи про це, я розумію, що така схема може дійсно мати свої застосування, тому я вирішив детальніше вивчити це.

Створення вебсайту на блокчейні

Ця стаття спробує розгорнути веб-сайт у TON і зробити його доступним через браузер. Увесь процес поділений на три етапи: 1. Купівля доменного імені; 2. Підготовка фронтенд-сторінки; 3. Прив'язка сторінки до доменного імені.

Концепція доменів у блокчейні подібна до світу Web2, обидві служать для надання псевдонімів складним і важким для запам'ятовування адресам. У блокчейні вони представляють адреси користувачів, тоді як у Web2 відповідають IP-адресам серверів.

Купівля домену

Наприклад, з TON можна купити домен через офіційний веб-сайт, ціна обчислюється в TON. Як і в Web2, чим коротше домен, тим вища його ціна, в межах від 1 до 100 TON.

Якщо домен ще не зареєстрований, ви можете зробити ставку за нижчою ціною, після чого розпочнеться етап зворотного відліку, під час якого всі можуть брати участь у торгах. Після виграшу домен буде збережений у вашому гаманці у вигляді NFT. Доменний NFT може бути проданий, термін дії становить 1 рік, після чого він буде вилучений.

Коротко кажучи, отримати домен можна через аукціон на офіційному сайті або купити у інших користувачів.

Підготовка фронтенд-сторінки

Цей крок потребує підготовки фронтенд-сторінки для відображення. Для спрощення операцій у цій статті підготовлено лише один HTML-файл, і він буде розгорнутий за допомогою nginx. Звичайно, також потрібен хмарний сервер для запуску фронтенд-сторінки. Цей процес схожий на традиційне розгортання фронтенд-додатків.

Прив'язка сторінки до .ton домену

Отримавши .ton домен, ви можете прив'язати свою ANDL адресу на офіційному сайті DNS TON. Ви також можете скористатися інструментом прив'язки, наданим TON, відповідно до офіційних інструкцій.

Після завершення прив’язки, також необхідно запустити на сервері прослуховуючий порт, який буде використовуватися для прийому HTTP запитів та їх пересилання у UDP. Можна використовувати офіційно наданий інструмент rldp-http-proxy, запустивши його за допомогою наступної команди:

rldp-http-proxy/rldp-http-proxy -p 8080 -c 3333 -C global.config.json

Серед них, 8080 - це TCP-порт для прослуховування вхідних HTTP-запитів, 3333 - це UDP-порт для активності RLDP та ADNL. global.config.json - це глобальний конфігураційний файл TON.

Доступ до .ton доменів

Пряме введення .ton домену в браузері неможливе, оскільки браузер не знає, як розпізнати такі домени. Тому потрібно виконати деякі додаткові налаштування.

Процес запиту .ton

При запиті доменного імені .ton спочатку відбувається запит до блокчейну на відповідну адресу ANDL, цей процес подібний до запиту DNS. Після цього запит буде перенаправлений на відповідну машину за адресою ANDL і поверне вказану сторінку. Весь процес подібний до Web2, основна різниця полягає в способі запиту відображення адреси та доменного імені.

Доступ до сторінки через代理

Рекомендується використовувати офіційно наданий інструмент Tonutils Reverse Proxy. Після установки та запуску він запустить проксі на порту 8080, після чого можна буде отримати доступ до домену .ton.

Використання підсумку

На даний момент у процесі використання виникли такі кілька проблем:

1. Є вимоги до середовища виконання: система повинна підтримувати версії glibc 2.34 та вище.

2. Документація недостатньо чітка: можливо, через низькі вимоги, написання документації не є достатньо досконалим, потрібно самостійно експериментувати. Оновлення китайської документації також не є достатньо своєчасним.

3. Повільна швидкість доступу: порівняно з традиційними веб-сайтами, швидкість доступу повільніша, але в майбутньому є великий потенціал для покращення.

4. Відсутність підтримки гаманців: Офіційно надано просту вбудовану браузерну сторінку, яка дозволяє отримати доступ без установки проксі. Але наразі основні гаманці розпізнають це як фішинговий сайт.

В цілому, поточний користувацький досвід є середнім, і є багато аспектів, які потребують покращення. Але цей напрямок є дуже інноваційним і вартий спроб та досліджень.