Nama seperti alice.eth terlihat seperti domain Internet, tetapi jalur resolusinya tidak sama dengan example.com. Domain konvensional biasanya masuk ke Domain Name System, tempat resolver mengikuti hierarki DNS untuk memperoleh record seperti A, AAAA, MX, atau TXT. Nama ENS masuk ke sistem penamaan berbeda yang state otoritatifnya dinyatakan melalui smart contract Ethereum.

Perbedaan inilah batas praktis di balik banyak klaim tentang “domain Web3”. Sebuah nama dapat bermakna secara global bagi software yang menerapkan resolusi ENS, tetapi tetap tidak dikenal oleh DNS resolver. Karena itu, browser, wallet, atau dApp membutuhkan jalur resolusi yang memahami ENS sebelum .eth dapat berfungsi sebagai nama yang berguna.

DNS dan ENS menggunakan protokol lookup yang berbeda

DNS memetakan nama melalui namespace hierarkis yang dioperasikan oleh DNS server:

aplikasi
    |
    v
DNS resolver
    |
    v
root -> TLD -> authoritative server
    |
    v
A / AAAA / MX / TXT / ...

Untuk website biasa, browser pada akhirnya membutuhkan IP address atau hasil DNS lain yang mengarahkannya ke origin yang diminta.

ENS menggunakan model protokol yang berbeda:

aplikasi
    |
    v
library atau provider yang memahami ENS
    |
    v
ENS Registry
    |
    v
Resolver contract
    |
    v
address / contenthash / text / record lain

Dokumentasi ENS mendeskripsikan ENS sebagai sistem penamaan terdistribusi berbasis Ethereum. Registry-nya menyimpan state terkait kepemilikan dan resolver yang terkait dengan sebuah nama. Resolver contract kemudian menyediakan record untuk nama tersebut.

DNS recursive resolver tidak otomatis melakukan query ke contract Ethereum itu. Sebaliknya, membaca record ENS untuk nama .eth native juga tidak memerlukan penelusuran hierarki DNS root.

Registry tidak menyimpan setiap record secara langsung

ENS Registry adalah titik awal resolusi, tetapi bukan tempat untuk menaruh semua record aplikasi.

Secara konseptual, registry menjawab pertanyaan seperti:

name node -> resolver mana yang menangani nama ini?

Resolver kemudian menjawab pertanyaan yang spesifik terhadap jenis record:

resolver.addr(node)        -> blockchain address
resolver.contenthash(node) -> content identifier
resolver.text(node, key)   -> text metadata

Pemisahan ini penting karena registry mengendalikan batas delegasi, sementara resolver contract dapat menerapkan perilaku record yang berbeda.

Public Resolver yang umum digunakan mendukung beberapa interface terstandardisasi. ENS juga mengizinkan implementasi resolver lain, sehingga aplikasi seharusnya melakukan resolusi berdasarkan resolver interface, bukan mengasumsikan bahwa seluruh nama menyimpan data dalam satu layout contract yang tetap.

Nama ENS di-encode sebelum lookup contract

Implementasi ENS tidak memakai string UTF-8 literal sebagai database key sederhana.

Nama terlebih dahulu harus dinormalisasi. ENS saat ini menetapkan normalisasi ENSIP-15 agar input pengguna yang ekuivalen menjadi bentuk kanonik sebelum proses hashing. Setelah normalisasi, nama diubah dengan namehash menjadi node identifier 32-byte yang dipakai contract.

Gambaran sederhananya:

"NaMe.EtH"
    |
    v
normalisasi ENS
    |
    v
"name.eth"
    |
    v
namehash
    |
    v
node ENS 32-byte

Ini membuat pemrosesan input menjadi bagian dari batas keamanan dan interoperabilitas. Dua aplikasi yang berbeda dalam melakukan normalisasi dapat menghasilkan node berbeda atau menampilkan nama yang membingungkan kepada pengguna.

Untuk software produksi, memakai library ENS yang terpelihara lebih aman daripada mengimplementasikan normalisasi dan penanganan namehash secara ad hoc.

ENS address record bukan web origin

Salah satu penggunaan ENS yang umum adalah memetakan nama yang mudah dibaca ke Ethereum address:

alice.eth
    |
    v
0x1234...abcd

Pemetaan ini berguna untuk wallet dan dApp, tetapi blockchain address bukan HTTP endpoint. Browser tidak dapat membuka website hanya karena sebuah nama ter-resolve ke akun Ethereum.

Publikasi web memerlukan pemetaan lain. ENS dapat menyimpan record contenthash yang mengidentifikasi konten pada sistem content-addressed yang didukung seperti IPFS.

Secara konseptual:

site.eth
    |
    v
ENS resolver
    |
    v
contenthash
    |
    v
content-addressed network atau gateway
    |
    v
konten situs

Langkah tambahan yang penting berada pada client atau gateway. Tetap harus ada komponen yang menginterpretasikan contenthash, mengambil konten yang terkait, lalu menyajikannya kepada pengguna.

Dukungan browser adalah persoalan lapisan resolusi

Mengetik site.eth ke browser tidak menjamin resolusi native.

Alur navigasi browser konvensional terintegrasi kuat dengan DNS dan HTTP(S). Nama ENS membutuhkan software yang mengenali ENS, melakukan query ke infrastruktur Ethereum yang sesuai, menginterpretasikan hasil resolver, lalu menentukan cara mengambil resource tujuan.

Dukungan tersebut dapat diberikan oleh beberapa komponen:

browser dengan dukungan ENS native/terintegrasi
            |
            +--> resolusi ENS

browser extension atau integrasi wallet
            |
            +--> resolusi ENS

HTTP gateway
            |
            +--> gateway melakukan resolusi ENS
                 dan menyajikan/mengambil konten

Masing-masing pendekatan memiliki trust boundary yang berbeda.

Pada resolusi langsung di sisi client, aplikasi melakukan atau mendelegasikan blockchain lookup melalui provider yang dikonfigurasi. Pada HTTP gateway, pengguna juga mempercayai gateway untuk menerjemahkan nama dan mengembalikan resource yang benar.

Karena itu, “dapat diakses melalui browser” dan “di-resolve secara native oleh browser” bukan pernyataan yang sama.

Gateway dapat menjembatani sistem tanpa menyatukannya

Gateway dapat mengekspos resource yang dikendalikan ENS melalui hostname HTTPS biasa.

Alurnya secara konseptual dapat berupa:

pengguna
  |
  v
https://gateway.example/site.eth
  |
  v
gateway
  |
  +--> resolve site.eth melalui ENS
  |
  +--> ambil target contenthash
  |
  v
HTTP response

Dari sudut pandang browser, DNS melakukan resolusi terhadap gateway.example. Setelah itu, gateway melakukan resolusi ENS atas nama browser.

Jembatan ini berguna, tetapi tidak mengubah .eth menjadi DNS top-level domain. Otoritas DNS tetap berada pada hostname konvensional milik gateway, sedangkan otoritas ENS menentukan record yang terkait dengan nama ENS.

Perbedaan tersebut penting bagi TLS, origin isolation, cookie, caching, pertahanan phishing, dan kebijakan apa pun yang bergantung pada origin model browser.

Kepemilikan dan registrasi berbeda dari resolusi

Resolusi menjelaskan cara menemukan record. Registrasi menjelaskan siapa yang mengendalikan nama dan berdasarkan aturan apa.

Untuk .eth, ENS menggunakan registrar contract. Registrasi memiliki aturan dan model renewal sendiri. Karena itu, sebuah nama tidak tepat disebut dimiliki permanen hanya karena state-nya direpresentasikan on-chain.

Pemisahan yang lebih akurat adalah:

registrar
   |
   +--> siapa yang boleh mengendalikan nama, dan berdasarkan aturan registrasi apa?

registry
   |
   +--> siapa owner/controller dan resolver apa yang dikonfigurasi?

resolver
   |
   +--> record apa yang dikembalikan nama tersebut?

Komponen tersebut saling berhubungan, tetapi menyelesaikan persoalan yang berbeda.

Pemisahan yang sama juga mencegah kekeliruan lain: memiliki wallet tidak otomatis memberi kendali atas sembarang nama. Kendali mengikuti aturan dan state dari registrar serta registry yang relevan.

ENS dapat berinteraksi dengan nama DNS tanpa menggantikan DNS

Secara konseptual ENS tidak terbatas pada .eth. ENS memiliki mekanisme untuk mengintegrasikan nama yang berasal dari DNS.

Integrasi tersebut tidak menghapus model otoritas DNS yang sudah ada. Sebaliknya, terbentuk jembatan di mana kendali atas nama DNS dapat dibuktikan lalu direpresentasikan di dalam ENS berdasarkan mekanisme integrasi yang didukung.

Hasilnya menimbulkan dua pertanyaan terpisah:

Siapa yang mengendalikan example.com di DNS?
Siapa yang mengendalikan representasinya di dalam ENS?

Integrasi yang benar harus mempertahankan hubungan otoritas tersebut, bukan sekadar mengizinkan wallet yang tidak terkait untuk mengklaim nama DNS yang sudah ada.

Ini menjadi alasan lain mengapa “domain Web3” merupakan istilah payung yang kurang presisi. Nama .eth native dan nama DNS yang diimpor ke ENS dapat memakai tooling resolusi yang sama, tetapi memiliki jalur registrasi dan otoritas berbeda.

Resolusi wallet dan resolusi website tidak boleh disamakan

Wallet biasanya membutuhkan tujuan blockchain yang dapat diproses mesin:

nama penerima -> blockchain address

Web client dapat membutuhkan hal berbeda:

nama situs -> contenthash -> konten

Aplikasi lain dapat meminta text metadata, avatar record, service endpoint, atau interface resolver lain.

Satu nama yang mudah dibaca karena itu dapat menyediakan beberapa record tanpa berarti semua software akan menginterpretasikannya secara identik.

Kode aplikasi sebaiknya meminta record yang benar-benar dibutuhkan. Memperlakukan setiap nama ENS seolah-olah merupakan HTTP hostname akan mencampur beberapa lapisan protokol menjadi satu abstraksi dan menghasilkan asumsi yang salah tentang konektivitas maupun kepercayaan.

Batas yang relevan adalah otoritas dan dukungan resolver

Sistem penamaan Web3 berguna ketika aplikasi sepakat mengenai dua hal: siapa yang memiliki otoritas untuk memperbarui nama, dan bagaimana record-nya di-resolve.

ENS menempatkan fungsi tersebut pada komponen protokol yang eksplisit:

otoritas registrasi
        |
        v
state registry
        |
        v
pemilihan resolver
        |
        v
lookup record bertipe
        |
        v
interpretasi aplikasi

DNS menyelesaikan persoalan faktor manusia yang serupa—mengubah nama menjadi informasi yang dapat diproses mesin—tetapi melalui arsitektur otoritas dan resolusi yang berbeda.

Karena itu, ENS tidak tepat diperlakukan sebagai pengganti DNS yang dapat dipasang begitu saja. ENS adalah sistem penamaan terpisah yang dapat diintegrasikan langsung oleh aplikasi atau dijembatani ke infrastruktur web konvensional. Perilaku praktis sebuah “domain Web3” akhirnya lebih ditentukan oleh jalur resolver, dukungan client, dan trust boundary yang dipakai untuk mengubah nama tersebut menjadi address atau resource daripada sekadar bentuk visual namanya.

Teknologi Web3 ENS DNS Ethereum