Sự hợp nhất ảnh hưởng đến lớp ứng dụng của Ethereum như thế nào

Rate this post

Quá trình chuyển đổi của Ethereum sang bằng chứng cổ phần – The Merge – đang gần kề: các devnet đang được đứng lên, các thông số kỹ thuật đang được hoàn thiện và hoạt động tiếp cận cộng đồng đã bắt đầu một cách nghiêm túc. Hợp nhất được thiết kế để có tác động tối thiểu đến cách Ethereum hoạt động cho người dùng cuối, hợp đồng thông minh và dapp. Điều đó nói rằng, có một số thay đổi nhỏ đáng chú ý. Trước khi chúng tôi đi sâu vào chúng, đây là một số liên kết để cung cấp ngữ cảnh về kiến ​​trúc Hợp nhất tổng thể:

Phần còn lại của bài đăng này sẽ cho rằng người đọc đã quen thuộc với những điều trên. Đối với những người muốn tìm hiểu sâu hơn, thông số kỹ thuật đầy đủ cho The Merge có sẵn tại đây:

Cấu trúc khối

Sau The Merge, bằng chứng về các khối công việc sẽ không còn tồn tại trên mạng nữa. Thay vào đó, nội dung trước đây của bằng chứng về khối công việc trở thành một thành phần của các khối được tạo trên Chuỗi báo hiệu. Sau đó, bạn có thể coi Beacon Chain trở thành lớp đồng thuận bằng chứng cổ phần mới của Ethereum, thay thế lớp đồng thuận bằng chứng công việc trước đó. Các khối chuỗi báo hiệu sẽ chứa ExecutionPayloadslà khối tương đương sau hợp nhất trên chuỗi công việc bằng chứng hiện tại. Hình ảnh dưới đây cho thấy mối quan hệ này:

Đối với người dùng cuối và nhà phát triển ứng dụng, những ExecutionPayloads là nơi các tương tác với Ethereum xảy ra. Các giao dịch trên lớp này vẫn sẽ được xử lý bởi các máy khách của lớp thực thi (Besu, Erigon, Geth, Nethermind, v.v.). May mắn thay, do sự ổn định của lớp thực thi, The Merge chỉ giới thiệu những thay đổi phá vỡ tối thiểu.

Khai thác & Trường khối Ommer

Sau hợp nhất, một số trường trước đây có trong tiêu đề bằng chứng khối công việc trở nên không được sử dụng vì chúng không liên quan đến bằng chứng cổ phần. Để giảm thiểu sự gián đoạn đối với công cụ và cơ sở hạ tầng, các trường này được đặt thành 0 hoặc tương đương với cấu trúc dữ liệu của chúng, thay vì bị loại bỏ hoàn toàn khỏi cấu trúc dữ liệu. Các thay đổi đầy đủ đối với các trường khối có thể được tìm thấy trong EIP-3675.

Đồng ruộng Giá trị hiện có Bình luận
sau tất cả [] RLP ([]) = 0xc0
sau tất cả 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 = Keccak256 (RLP ([]))
sự khó khăn 0
nonce 0x000000000000000000

Bởi vì bằng chứng cổ phần không tự nhiên tạo ra ommer (hay còn gọi là khối chú) giống như bằng chứng công việc, danh sách những thứ này trong mỗi khối (sau tất cả) sẽ trống và giá trị băm của danh sách này (sau tất cả) sẽ trở thành hàm băm được mã hóa RLP của một danh sách trống. Tương tự, vì sự khó khănnonce là các tính năng của bằng chứng công việc, các tính năng này sẽ được đặt thành 0đồng thời tôn trọng các giá trị kích thước byte của chúng.

mixHashmột lĩnh vực liên quan đến khai thác khác, sẽ không được đặt thành 0 mà thay vào đó sẽ chứa giá trị RANDAO của chuỗi beacon. Thêm về điều này bên dưới.

BLOCKHASH & SỰ KHÓ KHĂN thay đổi mã quang

Sau hợp nhất, BLOCKHASH opcode sẽ vẫn có sẵn để sử dụng, nhưng do nó sẽ không còn được giả mạo thông qua quá trình băm bằng chứng công việc, tính giả mạo do opcode này cung cấp sẽ yếu hơn nhiều.

Có liên quan, SỰ KHÓ KHĂN opcode (0x44) sẽ được cập nhật và đổi tên thành PREVRANDAO. Sau hợp nhất, nó sẽ trả về đầu ra của báo hiệu ngẫu nhiên được cung cấp bởi chuỗi báo hiệu. Do đó, mã opcode này sẽ là nguồn ngẫu nhiên mạnh hơn, mặc dù vẫn có thể thiên vị, cho các nhà phát triển ứng dụng sử dụng hơn là BLOCKHASH.

Giá trị được hiển thị bởi PREVRANDAO sẽ được lưu trữ trong ExecutionPayload ở đâu mixHashmột giá trị được liên kết với bằng chứng tính toán công việc, đã được lưu trữ. Tải trọng của mixHash trường cũng sẽ được đổi tên trướcRandao.

Đây là một minh họa về cách SỰ KHÓ KHĂN & PREVRANDAO mã opcodes hoạt động trước và sau khi hợp nhất:

Hợp nhất trước, chúng tôi thấy 0x44 opcode trả về sự khó khăn trong tiêu đề khối. Sau hợp nhất, mã opcode, được đổi tên thành PREVRANDAOtrỏ đến trường tiêu đề mà trước đó đã chứa mixHash và bây giờ lưu trữ trướcRandao giá trị từ trạng thái chuỗi đèn hiệu.

Thay đổi này, được chính thức hóa trong EIP-4399cũng cung cấp cho các ứng dụng trên chuỗi một cách để đánh giá xem Sự hợp nhất đã xảy ra hay chưa. Từ EIP:

Ngoài ra, các thay đổi do EIP này đề xuất cho phép các hợp đồng thông minh xác định xem việc nâng cấp lên PoS đã xảy ra hay chưa. Điều này có thể được thực hiện bằng cách phân tích giá trị trả về của SỰ KHÓ KHĂN opcode. Một giá trị lớn hơn 2 ** 64 cho biết rằng giao dịch đang được thực hiện trong khối PoS.

Chặn thời gian

Hợp nhất sẽ ảnh hưởng đến thời gian khối trung bình trên Ethereum. Hiện tại theo bằng chứng công việc, các khối xuất hiện trung bình sau mỗi ~ 13 giây với một lượng chênh lệch khá lớn trong thời gian khối thực tế. Theo bằng chứng về việc đặt cược, các khối sẽ xuất hiện chính xác sau mỗi 12 giây ngoại trừ khi một vị trí bị bỏ lỡ do trình xác thực ngoại tuyến hoặc do họ không gửi khối kịp thời. Trên thực tế, điều này hiện xảy ra ở <1% vị trí.

Điều này có nghĩa là giảm ~ 1 giây thời gian chặn trung bình trên mạng. Các hợp đồng thông minh giả định thời gian khối trung bình cụ thể trong tính toán của họ sẽ cần phải tính đến điều này.

Khối đã hoàn thiện & Đầu an toàn

Dưới bằng chứng công việc luôn có khả năng làm lại. Các ứng dụng thường đợi một số khối được khai thác trên đỉnh đầu mới trước khi coi nó là không có khả năng bị xóa khỏi chuỗi chuẩn hoặc “đã được xác nhận”. Sau khi Hợp nhất, chúng tôi thay vào đó có các khái niệm về hoàn thành khối và đầu an toàn hiển thị trên lớp thực thi. Các khối này có thể được sử dụng một cách đáng tin cậy hơn so với các khối công việc bằng chứng “đã được xác nhận” nhưng yêu cầu sự thay đổi trong hiểu biết để sử dụng chính xác.

Khối đã hoàn thiện là khối đã được> 2/3 số người xác nhận chấp nhận là chuẩn. Để tạo ra một khối xung đột, kẻ tấn công sẽ phải đốt ít nhất 1/3 tổng số ether đã đặt cọc. Mặc dù số tiền đặt cược có thể khác nhau, nhưng một cuộc tấn công như vậy luôn dự kiến ​​sẽ khiến kẻ tấn công thiệt hại hàng triệu ETH.

Một đầu an toàn khối là một trong đó đã được chính đáng bởi Beacon Chain, có nghĩa là> 2/3 số người xác nhận đã chứng thực nó. Trong điều kiện mạng bình thường, chúng tôi hy vọng nó sẽ được đưa vào chuỗi chuẩn và cuối cùng được hoàn thiện. Để khối này không phải là một phần của chuỗi chuẩn, phần lớn trình xác nhận sẽ cần phải thông đồng để tấn công mạng hoặc mạng sẽ phải trải qua mức độ trễ cực kỳ lớn trong quá trình truyền khối. Các API lớp thực thi, hậu hợp nhất (ví dụ: JSON RPC) sẽ hiển thị đầu an toàn sử dụng một an toàn nhãn.

Các khối đã hoàn thiện cũng sẽ được hiển thị qua JSON RPC, thông qua một hoàn thành lá cờ. Sau đó, chúng có thể thay thế mạnh mẽ hơn cho bằng chứng xác nhận công việc. Bảng dưới đây tóm tắt điều này:

Loại khối Cơ chế đồng thuận JSON RPC Điều kiện để tổ chức lại
cái đầu Bằng chứng làm việc muộn nhất Để được mong đợi, phải được sử dụng cẩn thận.
đầu an toàn Bằng chứng cổ phần an toàn Có thể, yêu cầu độ trễ mạng lớn hoặc bị tấn công trên mạng.
đã xác nhận Bằng chứng làm việc N / A Không có khả năng, yêu cầu phần lớn hashrate để khai thác một chuỗi cạnh tranh có độ sâu> # xác nhận.
hoàn thành Bằng chứng cổ phần hoàn thành Rất khó xảy ra, yêu cầu> 2/3 trình xác thực để hoàn thành chuỗi cạnh tranh, yêu cầu ít nhất 1/3 bị cắt.

Lưu ý: đặc tả JSON RPC vẫn đang được phát triển tích cực. Thay đổi tên vẫn nên được mong đợi.

Bước tiếp theo

Chúng tôi hy vọng bài đăng này sẽ giúp các nhà phát triển ứng dụng chuẩn bị cho quá trình chuyển đổi được mong đợi nhiều sang bằng chứng cổ phần. Trong vài tuần tới, một mạng thử nghiệm tồn tại lâu dài sẽ được cung cấp để thử nghiệm bởi cộng đồng rộng lớn hơn. Ngoài ra còn có một Hợp nhất cuộc gọi cộng đồng để các nhà phát triển cơ sở hạ tầng, công cụ và ứng dụng đặt câu hỏi và nghe cập nhật kỹ thuật mới nhất về The Merge. Hẹn gặp lại các bạn 👋🏻


Cảm ơn Mikhail Kalinin, Danny Ryan & Matt Garnett đã xem xét các bản nháp của bài đăng này.

Thuc Quyen

Leave a Reply

Your email address will not be published. Required fields are marked *