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 xây dựng, 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 đối với 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ể:

• Sự phát triển của lộ trình
• Kiến trúc ứng dụng khách sau hợp nhất

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:

• Lớp thực thi
• Lớp đồng thuận
• API động cơ

Cấu trúc khối

Sau khi Hợp nhất, 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 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 ExecutionPayloads , là 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, ExecutionPayloads này 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 nhỏ nhất.

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ị xóa hoàn toàn khỏi cấu trúc dữ liệu. Bạn có thể tìm thấy các thay đổi đầy đủ đối với các trường khối trong EIP-3675.

Trường Giá trị không đổi Nhận xét ommers [] RLP ([]) =0xc0 ommersHash 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 =Keccak256 (RLP ([])) khó 0 nonce 0x0000000000000000

Bởi vì bằng chứng cổ phần không tự nhiên tạo ra ommers (còn gọi là khối chú thí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 ( ommers ) sẽ trống và giá trị băm của danh sách này ( ommersHash ) 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ì khó và nonce 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.

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

BLOCKHASH & DIFFICULTY thay đổi mã opcodes

Hậu 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, DIFFICULTY opcode ( 0x44 ) sẽ được cập nhật và đổi tên thành RANDOM . 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 đó, 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 BLOCKHASH .

Giá trị được hiển thị bởi RANDOM sẽ được lưu trữ trong ExecutionPayload nơi mixHash , mộ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ữ. mixHash của payload trường cũng sẽ được đổi tên thành random .

Đây là minh họa về cách DIFFICULTY & NGẪU NHIÊN 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ề khó trong tiêu đề khối. Sau hợp nhất, opcode, được đổi tên thành RANDOM , trỏ đến trường tiêu đề trước đó chứa mixHash và bây giờ lưu trữ random giá trị từ trạng thái chuỗi báo hiệu.

Thay đổi này, được chính thức hóa trong EIP-4399, cũng cung cấp cho các ứng dụng trên chuỗi một cách để đánh giá xem việc Hợp nhất có xảy ra hay không. 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 opcode DIFFICULTY. 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.

Thời gian chặn

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 sai lệch hợp lý trong thời gian khối thực tế. Theo bằng chứng về tiền 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 khoảng 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 chúng sẽ cần phải tính đến điều này.

Phần đầu An toàn &Khối đã hoàn thiện

Dưới bằng chứng về 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, thay vào đó, chúng tôi có các khái niệm về cuối cùng và đầu an toàn các khối. Những khối này thậm chí có thể được sử dụng đáng tin cậy hơn so với bằng chứng “đã được xác nhận” về các khối công việc nhưng cần có sự thay đổi trong hiểu biết để sử dụng đúng cách.

Khối đã hoàn thiện là khối đã được> 2/3 số người xác thực 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ố tiền đặt cược. Tại thời điểm viết bài này, con số này đại diện cho hơn 10 tỷ đô la (hoặc> 2,5 triệu ETH) trên Ethereum.

Đ ầu an toàn khối là khối, trong điều kiện mạng bình thường, chúng tôi mong đợi sẽ được đưa vào chuỗi chuẩn. Giả sử mạng có độ trễ ít hơn 4 giây, phần lớn người xác thực trung thực và không có cuộc tấn công nào vào quy tắc lựa chọn rẽ nhánh, phần đầu an toàn sẽ không bao giờ mồ côi. Bài trình bày chi tiết cách tính toán giới hạn an toàn trong các tình huống khác nhau có sẵn tại đây. Ngoài ra, các giả định và đảm bảo về đầu an toàn đang được chính thức xác định và phân tích trong một bài báo sắp tới.

Các API lớp thực thi, hậu hợp nhất (ví dụ:JSON RPC) sẽ trả về phần đầu an toàn theo mặc định khi được hỏi về mới nhất khối. Trong điều kiện mạng bình thường, đầu an toàn và đầu dây thực tế của chuỗi sẽ tương đương (với dấu vết đầu an toàn chỉ trong vài giây). Đầu an toàn sẽ ít có khả năng bị thay đổi hơn so với bằng chứng công việc hiện tại mới nhất các khối. Để hiển thị mẹo thực tế của chuỗi bằng chứng cổ phần, không an toàn cờ sẽ được thêm vào JSON RPC.

Các khối đã hoàn thiện cũng sẽ được hiển thị qua JSON RPC, thông qua mới hoàn thiện 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 đầu Proof of Work mới nhất Để được mong đợi, phải được sử dụng cẩn thận. đầu Bằng chứng về Cổ phần không an toàn Để được mong đợi, phải được sử dụng cẩn thận. đầu an toàn Proof of Stake mới nhất 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 công việc Không có khả năng xảy ra, yêu cầu phần lớn tỷ lệ băm để 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 và yêu cầu ít nhất 1/3 bị cắt.

Các 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 cuộc gọi cộng đồng Merge sắp tới dành cho 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 vì đã cung cấp nội dung cốt lõi của phần “Đầu an toàn” và Danny Ryan &Matt Garnett đã xem xét các bản nháp của bài đăng này.