Khoa học phổ biến: Địa chỉ mạng trong Ethereum
Lưu ý của biên tập viên: Bài viết này đến từUnitimes(ID:Uni-times)Lưu ý của biên tập viên: Bài viết này đến từ
Sau khi thảo luận với Felix Lange, tôi nghĩ sẽ rất hợp lý khi viết bài này về các loại địa chỉ mạng khác nhau gặp phải trong hệ sinh thái Ethereum và sự khác biệt của chúng. Tôi cũng có một số hiểu lầm trong cách hiểu của mình về chúng, vì vậy tôi nghĩ rằng việc giải thích chúng sẽ rất có giá trị.
tiêu đề phụ
Đa địa chỉ (Multiaddr)
Hãy bắt đầu với multiaddr sớm nhất (Multiaddr[1]) đã được lưu trữ hoặc theo thời gian cam kết. Đa địa chỉ là một phần của dự án đa định dạng của Phòng thí nghiệm giao thức. Đa định dạng về cơ bản là các thông số kỹ thuật khác nhau của các giá trị tự mô tả. Có thể bạn đã nghe nói về chúng, do chúng được sử dụng rộng rãi trong libp2p, IPFS và các dự án Phòng thí nghiệm giao thức khác.
/ip4/127.0.0.1/udp/1234
Có hai biểu diễn của đa địa chỉ: một là biểu diễn nhị phân được sử dụng khi lưu trữ hoặc truyền; hai là định dạng có thể đọc được cung cấp cho người dùng., }). Biểu diễn nhị phân cũng giống như vậy - có một mảng byte cho các khóa và một mảng khác cho các giá trị. Các khóa có thể được ánh xạ từ dạng con người có thể đọc được sang dạng được mã hóa thông qua các bảng giao thức [2].
enode
tiêu đề phụ
enode://6f8a80d6ad92a0@10.3.58.6:30303?discport=30301
Hệ thống enode được sử dụng để đại diện cho các URL. enode:// theo sau là ID nút được mã hóa hex. Tiếp theo, biểu tượng @ cho biết máy chủ, phải là địa chỉ IP. Cổng TCP được liệt kê sau máy chủ, trong trường hợp của chúng tôi là 30303. Nếu các cổng của UDP và TCP khác nhau, cổng UDP có thể được chỉ định bằng cách thêm tham số discport vào cuối.
ENR
tiêu đề phụ
Cuối cùng, chúng ta đến với ENR[4] (Bản ghi nút Ethereum). ENR rất thú vị vì nó sử dụng các tính năng từ cả hai loại đầu tiên (nhiều địa chỉ và URL mã hóa), khiến nó trở nên rất chung chung. Động lực chính của ENR là cho phép mang nhiều thông tin hơn trong quá trình chuyển tiếp, do đó giới thiệu các bản ghi nút. Các bản ghi nút tự xác nhận và các nút có thể tự nhận dạng thông qua chữ ký. Các bản ghi này được biểu diễn dưới dạng danh sách RLP [5] - Tôi sẽ không đi vào chi tiết ở đây, nhưng có một đề cập nhỏ, RLP là một định dạng tuần tự hóa được Ethereum sử dụng.
Bản ghi nút chứa chữ ký, số sê-ri và trường cho biết cơ chế xác thực được sử dụng để tạo và xác minh chữ ký. Cuối cùng, phần còn lại của bản ghi chứa các cặp khóa-giá trị tùy ý có thể chứa những thứ như thông tin kết nối. EIP xác định một số khóa có ý nghĩa được xác định trước, chẳng hạn như ip, là địa chỉ IPv4 của nút được biểu thị bằng 4 byte.
Chữ ký được sử dụng để xác minh bản ghi bằng cách đảm bảo rằng khóa chung được chuyển là khóa được sử dụng để tạo chữ ký.
Nếu cùng một danh tính phát hành 2 bản ghi khác nhau, thì số sê-ri có thể được sử dụng để giải quyết xung đột: bản ghi có số sê-ri cao hơn được chỉ định.
Định dạng này là minh chứng cho tương lai, các khóa mới có thể được thêm vào ngay cả khi một số khách hàng không thể phân tích cú pháp và các cơ chế xác thực mới có thể được thêm vào để xác minh chữ ký.
Eth 2.0
tiêu đề phụ
Bây giờ, hãy xem Eth2.0. Trước Eth2.0, không bao giờ có nhiều địa chỉ trong Ethereum, nhưng bây giờ chúng rất quan trọng. Tại sao? Bởi vì Eth2.0 sử dụng libp2p và libp2p sử dụng nhiều địa chỉ để xác định các nút.
Vì vậy, làm thế nào để chúng ta xử lý tình huống này? Đặc tả P2P [6] của Eth2.0 cho thấy hai giải pháp:
Có thể xuất nhiều địa chỉ từ ENR
Vì ENR có thể thêm các khóa tùy ý nên có thể bao gồm nhiều địa chỉ trong ENR.


