Nguồn ban đầu: Cập nhật AllCoreDevs
Nguồn ban đầu: Cập nhật AllCoreDevs
Tác giả: Tim Beiko
Tổng hợp gốc: Ethereum.cn
Chào mừng bạn đến với bản cập nhật AllCoreDevs (Ethereum Core Developers Conference) mới - bản cuối cùng cho năm 2022.
Mặc dù các bản cập nhật này bắt đầu dưới dạng một chuỗi hàng tháng, nhịp điệu đã dần chuyển sang bản cập nhật hàng quý. Người đọc có thể coi những cập nhật này như một bản tóm tắt các sự kiện chính xung quanh AllCoreDevs. Nếu bạn muốn biết thêm chi tiết, tôi khuyên bạn nên đọc bản ghi của Christine Kim, bản ghi cuộc họp lớp đồng thuận của Ben Edginton và các tweet dài ACD của tôi, được cập nhật thường xuyên hơn.
bản tóm tắt
bản tóm tắt
Nội dung của bản nâng cấp Shanghai/Capella đã được hoàn thiện: rút tiền, EOF và một số sửa lỗi nhỏ...miễn là chúng không trì hoãn việc rút tiền
Không gian blob sắp ra mắt: EIP-4844 sẽ là trung tâm của bản nâng cấp tiếp theo của Ethereum và lễ triệu tập của nó sẽ sớm bắt đầu
Về mặt kỹ thuật, các nỗ lực đang được tiến hành để điều phối quá trình nâng cấp lớp thực thi và lớp đồng thuận. Chúng tôi cũng đang thấy các cuộc thảo luận tích cực về việc kết hợp tốt hơn ý kiến đóng góp của cộng đồng vào quy trình
tiêu đề cấp đầu tiên
Nâng cấp Thượng Hải/Capella
Tại AllCoreDevs gần đây, nhóm khách hàng đã đi đến thống nhất về phạm vi nâng cấp cuối cùng của Shanghai/Capella. Mặc dù tên của bản nâng cấp có thể gây tranh cãi nhưng nhóm đã hiểu rõ về phạm vi của nó. Chức năng chính của việc nâng cấp là giới thiệu rút tiền chuỗi đèn hiệu cho người đặt cược. Việc đưa tính năng này ra mắt càng sớm càng tốt là điều mà nhóm khách hàng không muốn thỏa hiệp, vì vậy các tính năng khác trong bản nâng cấp cần phải sẵn sàng cùng lúc, nếu không chúng có thể bị loại bỏ.
Thông số kỹ thuật điều hành Thượng Hải liệt kê tất cả các EIP được tích hợp:
EIP-3540: Định dạng Đối tượng EVM (EOF) v1
EIP-3651: Giảm chi phí gas khi truy cập các địa chỉ COINBASE
EIP-3670: EOF - Xác thực mã
EIP-3855: Opcode mới PUSH 0
EIP-3860: Giới hạn kích thước mã khởi tạo và giới thiệu đo khí
EIP-4200: EOF - bước nhảy tương đối tĩnh
EIP-4750: EOF - chức năng nhập
EIP-4895: Rút tiền đẩy Beacon Chain như một hoạt động của hệ thống
EIP-5450: EOF - Xác thực ngăn xếp
tiêu đề phụ
cải tiến nhỏ
EIP-3651: COINBASE ấm (giảm chi phí gas khi truy cập các địa chỉ COINBASE)
EIP này khắc phục lỗi giám sát trong EIP-2929 trong đó việc sửa đổi chi phí gas đối với một số truy cập trường dữ liệu nhất định dựa trên việc dữ liệu đã có trong bộ nhớ máy khách (WARM) hay cần được truy xuất từ đĩa (COLD) .
EIP-2929 đặt hai phần dữ liệu trong bộ nhớ máy khách thành WARM khi bắt đầu mỗi giao dịch: địa chỉ gửi và địa chỉ nhận. EIP-3651 thêm địa chỉ thứ ba vào danh sách này, địa chỉ COINBASE (tức là người nhận phí), vì đây cũng là địa chỉ mà khách hàng có trong bộ nhớ khi xử lý các giao dịch khối.
EIP-3855: Lệnh PUSH 0 (thêm opcode `PUSH 0)
Như tên cho thấy, EIP-3855 giới thiệu một opcode đẩy giá trị 0 vào ngăn xếp. Việc đẩy các số 0 thường được sử dụng để điền các giá trị trong EVM, opcode này sẽ cung cấp một cách hiệu quả hơn và rẻ hơn để thực hiện việc này.
EIP-3860: Mã khởi tạo giới hạn và đo (đặt giới hạn về kích thước của mã khởi tạo và giới thiệu đo khí)
EIP này thêm giới hạn về kích thước của mã khởi tạo và giới thiệu tính năng đo khí dựa trên độ dài của nó. Giới hạn kích thước của nó thêm một bất biến vào EVM, giúp dễ hiểu và đề xuất các thay đổi hơn.
tiêu đề phụ
định dạng đối tượng
Hầu hết các EIP có trong bản nâng cấp Thượng Hải thực sự là một phần của một tính năng duy nhất: Định dạng Đối tượng EVM (EOF). Công việc này được chia thành 5 EIP khác nhau để giúp các nhà phát triển khách hàng hiểu từng sửa đổi riêng lẻ, nhưng để cung cấp cái nhìn tổng quan ở cấp độ cao hơn, các nhà phát triển đã xuất bản một đặc điểm kỹ thuật tổng hợp. EIP của năm EOF là:
EIP-3540: Định dạng đối tượng EVM Phiên bản 1
EIP-3670: EOF - Xác thực mã
EIP-4200: EOF - bước nhảy tương đối tĩnh
EIP-4750: EOF - chức năng nhập
EIP-5450: EOF - Xác thực ngăn xếp
Điều đáng chú ý là bước đầu tiên của EOF đã xảy ra ở EIP-3541 được nâng cấp ở Luân Đôn, dành riêng tiền tố 0xEF 00 cho các hợp đồng EOF. Phạm vi EOF cho bản nâng cấp Thượng Hải cũng đã thay đổi trong vài tháng qua.
Vào tháng 2, nhóm khách hàng đã đồng ý xem xét nâng cấp ở Thượng Hải để kết hợp hai EIP EOF nhỏ nhất: EIP 3540 & 3670. Tất cả chúng sẽ đóng vai trò là các khối xây dựng, nhưng nếu không có sự ra đời của EIP 4200, 4750 và 5450, chúng sẽ không cung cấp đầy đủ chức năng. Mặc dù có thể mở rộng EOF, nhưng khả năng không tương thích ngược có thể yêu cầu phiên bản mới. Vì các hợp đồng trước EOF hoặc với một phiên bản cụ thể của EOF phải luôn được thực thi, mỗi phiên bản EOF mới có nghĩa là các nhà phát triển ứng dụng khách phải duy trì một bộ quy tắc thực thi EVM mới song song với các quy tắc cũ.
Trước EOF, khách hàng chỉ duy trì một bộ quy tắc EVM tại một thời điểm. Cơ sở mã cũng hỗ trợ các quy tắc EVM trước đó, được sửa đổi trong mỗi lần nâng cấp mạng, nhưng khi chúng đạt đến phần đầu của chuỗi khối, thì chỉ các quy tắc mới nhất phải được áp dụng. Sau khi triển khai EOF, khách hàng sẽ duy trì song song hai bộ quy tắc EVM để họ có thể thực thi mã trong hợp đồng EOF và không phải EOF. Nói cách khác, các phiên bản gia tăng của EOF làm tăng số lượng bộ quy tắc EVM song song thay vì tuần tự phải được duy trì.
Vì lý do này, trong vài tháng qua, nhóm khách hàng bắt đầu ưa chuộng "EOF lớn"phương pháp. Bằng cách này, mặc dù họ phải triển khai bộ sửa đổi lớn hơn, nhưng phiên bản EOF sẽ tồn tại lâu hơn và giảm "EVM song song" cần được duy trì"con số. Do đó, các nhà phát triển đã coi "EOF lớn" và cuối cùng đã kết hợp nó vào bản nâng cấp Thượng Hải.
Điều đó nói rằng, các tính năng lớn hơn rõ ràng là khó triển khai và thử nghiệm hơn, đồng thời nhóm không muốn thấy EOF trì hoãn đáng kể việc rút tiền chuỗi đèn hiệu. Do đó, nếu việc triển khai EOF chưa được hoàn thành vào tháng 1 và không thể tương tác nhanh với nhau, thì nhóm khách hàng đồng ý chuyển EOF ra khỏi Thượng Hải để nâng cấp.
EIP-3540: Định dạng Đối tượng EVM (EOF) v1 (Định dạng Đối tượng EVM Phiên bản 1)
EIP-3540: Định dạng Đối tượng EVM (EOF) v1 (Định dạng Đối tượng EVM Phiên bản 1)
EIP này giới thiệu một "vùng chứa" cho các hợp đồng EOF. Nó bổ sung các điểm đánh dấu để phân biệt các phần mã và dữ liệu của hợp đồng, đồng thời ngăn triển khai các hợp đồng EOF không tuân theo định dạng. Điều này đảm bảo rằng mọi hợp đồng EOF trên chuỗi sẽ tuân theo định dạng hợp lệ, giúp đơn giản hóa việc tương tác với các hợp đồng này, cũng như phân tích tĩnh về chúng.
EIP-3670: EOF - Xác thực mã (EOF - Xác thực mã)
Dựa trên vùng chứa được giới thiệu bởi 3540, EIP-3670 đảm bảo rằng mã trong hợp đồng EOF hợp lệ hoặc ngăn không cho nó được triển khai.
Điều này có nghĩa là các mã lệnh không xác định không thể được triển khai trong các hợp đồng EOF, điều này có thêm lợi ích là giảm số lượng phiên bản EOF cần được thêm vào. Nếu một mã thao tác mới được thêm vào, quy tắc xác thực có thể được thay đổi đơn giản để kích hoạt mã đó và đảm bảo rằng không có hợp đồng EOF đã triển khai nào tham chiếu mã đó trong phần mã của nó.
EIP-4200: EOF - Bước nhảy tương đối tĩnh (EOF - Bước nhảy tương đối tĩnh)
EIP-4200 đã giới thiệu các opcode dành riêng cho EOF đầu tiên: RJUMP, RJUMPI và RJUMPV, mã hóa các điểm đến dưới dạng các giá trị ngay lập tức được ký. Các mã lệnh JUMP mới này có thể được các trình biên dịch sử dụng để tối ưu hóa chi phí gas, vì chúng loại bỏ nhu cầu phân tích bước nhảy cao nhất trong thời gian chạy, vốn được yêu cầu bởi các mã lệnh JUMP & JUMPI hiện có.
EIP-4750: EOF - Hàm (các hàm được nhập từ EOF)
EIP-4750 xây dựng trên 4200 một bước xa hơn: nó không cho phép các opcode JUMP & JUMPI và thêm các lựa chọn thay thế cho các chức năng RJUMP, RJUMPI và RJUMPV không thể sao chép. Nó thực hiện điều này bằng cách giới thiệu một phần các chức năng cụ thể trong mã byte EOF có thể được nhảy tới, được gọi và trả về bằng cách sử dụng mã op JUMPF, CALLF và RETF mới tương ứng.
EIP-5450: EOF - Xác thực ngăn xếp (EOF-Xác thực ngăn xếp)
Cuối cùng, EIP-5450 thêm một kiểm tra xác thực khác cho các hợp đồng EOF, lần này là xung quanh ngăn xếp. EIP này ngăn việc triển khai hợp đồng EOF có khả năng gây tràn ngăn xếp và mã bị tràn trong một số trường hợp. Với EIP này, khách hàng có thể giảm số lần kiểm tra xác thực khi thực hiện hợp đồng EOF, vì họ có đảm bảo tốt hơn về các ngoại lệ liên quan đến ngăn xếp.
tiêu đề phụ
Rút tiền theo chuỗi Beacon
Cuối cùng nhưng không kém phần quan trọng, phần chính của "Shapella" (Ghi chú của người dịch: tên chung của Shanghai/Capella) là việc rút chuỗi đèn hiệu. Phần thay đổi này được mô tả trong đặc tả lớp đồng thuận và EIP-4895. Hiện tại có một đặc điểm kỹ thuật meta hơi lỗi thời liên kết những thay đổi này lại với nhau.
Ở cấp độ cao, cơ chế rút tiền như sau:
Khi đề xuất một khối, trình xác thực quét tuyến tính chỉ mục trình xác thực để tìm 16 trình xác thực đầu tiên có chứng chỉ 0x01, những trình xác thực này cần đáp ứng một trong các điều kiện sau:
Have a balance above 32 ETH (i.e. have accrued validator rewards)
Are withdrawable (i.e. have fully exited the validator set)
Số dư lớn hơn 32 ETH (nghĩa là đã nhận được phần thưởng trình xác thực)
có thể rút được (có thể rút được, nghĩa là đã rút hoàn toàn khỏi bộ xác thực)
From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:
Trình xác thực sẽ tạo danh sách rút tiền từ các trình xác thực này để đóng gói vào ExecutPayload của họ. Mỗi mục trong danh sách chứa những điều sau đây:
Withdrawal Index: Chỉ số của tất cả các giao dịch rút tiền đã được thực hiện - điều này giúp phân biệt các lần rút tiền có cùng số tiền từ cùng một địa chỉ, cùng một trình xác thực
ValidatorIndex: Chỉ số xác thực có số dư đã tăng
Địa chỉ thực thi: Địa chỉ ETH của lớp thực thi, nơi gửi tiền rút
Số tiền: Số tiền được gửi đến Địa chỉ thực thi, số tiền này được đo bằng gwei (không phải wei)
Khi xây dựng hoặc xử lý một khối, ứng dụng khách lớp thực thi sẽ thực hiện các hoạt động rút tiền này sau khi giao dịch được thực hiện. Nói cách khác, việc rút tiền được xử lý tương tự như cách phần thưởng bằng chứng công việc được ghi có và nó không cạnh tranh với các giao dịch của người dùng về không gian khối.
Ngoài ra còn có một số chi tiết đáng chú ý:
Khi xử lý việc rút tiền, không có sự khác biệt về mức độ ưu tiên/xếp hạng giữa việc gửi "Số tiền đầy đủ" so với "Số tiền một phần". Toàn bộ số tiền được rút khi trình xác thực rời khỏi nhóm thoát, trong khi việc rút một phần diễn ra định kỳ, khi quá trình quét tuyến tính của bộ trình xác thực được thực hiện và số chỉ mục của trình xác thực nhất định được quét.
Để việc rút tiền được xử lý, trình xác thực phải sử dụng mã thông báo 0x01, được biểu thị bằng địa chỉ ETH. Chỉ cho phép thông tin đăng nhập cặp khóa BLS 0x00 khi chuỗi báo hiệu hoạt động. Để bắt đầu rút tiền, những người xác thực có thông tin đăng nhập 0x00 sẽ cần phải ký một thông báo BLSToExecutionChange. Chúng sẽ được kích hoạt trong bản nâng cấp Capella. Sẽ có nhiều công cụ khác nhau được sử dụng để ký thông báo này và những người xác nhận có thể mong đợi hỗ trợ và hướng dẫn cho những công cụ này.
Trình xác nhận được quét trên cơ sở mỗi khối. Nếu không có quá 16 lần rút tiền để xử lý sau khi quét một tập hợp con của bộ trình xác thực, trình xác thực sẽ dừng quét và trình xác thực tiếp theo sẽ bắt đầu từ chỉ mục trình xác thực cuối cùng được quét.
Như thường lệ, trước khi mạng chính đi vào hoạt động, sẽ có một số mạng thử nghiệm và mạng thử nghiệm dành cho nhà phát triển (thậm chí có thể là một số mạng thử nghiệm mới!) Để trình xác thực chạy qua và giải quyết mọi vấn đề khó khăn.
tiêu đề cấp đầu tiên
nâng cấp cancun
Do nội dung nâng cấp ở Thượng Hải đã đầy nên nhiều EIP (CFI) được xem xét nâng cấp đã không thể tham gia nâng cấp ở Thượng Hải. Nhóm khách hàng bắt đầu thảo luận về EIP nào sẽ được xem xét cho lần nâng cấp tiếp theo: Nâng cấp Cancun (tên lớp đồng thuận sẽ được xác định)
Về lớp đồng thuận, EIP-4844 đã trở thành EIP đầu tiên được ghi vào thông số kỹ thuật sau khi nâng cấp Capella. Lớp điều hành không (chưa) có thông số kỹ thuật sẽ triển khai bố cục này, nhưng nhóm lớp điều hành đã đồng ý đi theo một con đường tương tự, với EIP-4844 là trung tâm của bản nâng cấp tiếp theo.
Theo quy ước nâng cấp để sử dụng tên của thành phố tổ chức Devcon, cancun.md đã được tạo, trong đó EIP-4844 chính thức được đưa vào bản nâng cấp.
tiêu đề phụ
lễ KZG
Một điều khác có thể được mong đợi liên quan đến việc nâng cấp Cancun là buổi lễ KZG, đây là một yêu cầu của EIP-4844.
Nghi thức này sẽ tạo ra tính ngẫu nhiên cần thiết để xác minh tính hợp lệ của dữ liệu đốm màu. Để nó được coi là an toàn, chỉ cần một người tham gia trung thực. Nói cách khác, nếu tất cả ngoại trừ một người thông đồng, toàn bộ quá trình sẽ được bảo mật bằng mật mã.
tiêu đề cấp đầu tiên
Quá trình nâng cấp sau sáp nhập
Như đã đề cập trong bản cập nhật trước, sau khi hợp nhất, việc điều phối quá trình nâng cấp của Ethereum ở lớp thực thi và đồng thuận là một công việc tồn đọng quan trọng. Ở cấp độ cao, lớp thực thi sử dụng Sách vàng & EIP để chỉ định các sửa đổi, trong khi lớp đồng thuận sử dụng các thông số kỹ thuật Python có thể thực thi được.
Lợi ích của quy trình cấp điều hành là EIP được cộng đồng biết đến và được định dạng theo cách thể hiện rõ ràng lý do đằng sau đề xuất. Giấy màu vàng nặng về toán học được kết hợp với EIP và nhu cầu đưa thông số kỹ thuật trở lại ngữ cảnh của từng EIP khiến cho thông số kỹ thuật cấp triển khai trở nên khó hiểu và khó mở rộng.
Vấn đề với lớp đồng thuận thì ngược lại: nó có đặc điểm kỹ thuật rõ ràng và dễ hiểu, trong một kho lưu trữ duy nhất, nhưng các thay đổi không rõ ràng cụ thể và các đề xuất bị chìm trong các PR công khai khác trong kho lưu trữ.
Với việc giới thiệu đặc tả Lớp thực thi Ethereum, chúng tôi hy vọng sẽ thu hẹp khoảng cách này từ góc độ lớp thực thi. Và, với một số tranh cãi về quy trình, chúng tôi có thể đưa EIP vào quy trình lớp đồng thuận!
Điều đó nói rằng, khi phạm vi nâng cấp của Thượng Hải đã được thảo luận và hoàn thiện, rõ ràng là có thể thiếu một phần khác của quy trình: yêu cầu cộng đồng bày tỏ sở thích tương đối của họ đối với các thay đổi và tham gia vào các cuộc thảo luận về phạm vi nâng cấp tổng thể (chứ không phải các EIP riêng lẻ) Thảo luận về vị trí của nó và biến nó thành một phần của các quyết định tại các cuộc họp của AllCoreDevs và Lớp đồng thuận.
Không rõ nó sẽ như thế nào - Tôi rất muốn nhận được những gợi ý! — nhưng với cả số lượng các bên liên quan tích cực tham gia vào các thay đổi giao thức và số lượng miền bị ảnh hưởng bởi các thay đổi lớp ngày càng tăng, rõ ràng chúng tôi cần một thứ gì đó.
May mắn thay, chúng ta không cần phải bắt đầu lại từ đầu. Ethereum Magicians đã tồn tại trong nhiều năm và các cuộc gặp gỡ, cuộc họp nhóm chuyên dụng hoặc cuộc họp cộng đồng có thể là điểm khởi đầu tốt để mở rộng quy mô.
tiêu đề cấp đầu tiên
Cập nhật bang hội giao thức
Với việc thử nghiệm Hiệp hội Giao thức (PG) đã hoàn thành được nửa chặng đường, họ đã phát hành một báo cáo xem xét mọi thứ đang diễn ra như thế nào và suy nghĩ về những gì tiếp theo cho dự án.
Xin nhắc lại, PG là một cơ chế tài trợ không được phép dành cho các nhà phát triển ứng dụng khách Ethereum Lớp 1, nhà nghiên cứu giao thức và những người đóng góp hỗ trợ như bạn.
Cơ chế này tập trung vào cá nhân, không phải tổ chức. Nói tóm lại, mỗi thành viên được hưởng một phần mã thông báo của bang hội, được tính theo thời gian họ đã đóng góp cho Ethereum. Việc thêm và xóa thành viên được thực hiện theo cách thực sự của Ethereum - dựa trên một bộ tiêu chuẩn, đạt được sự đồng thuận chung trong PG. Danh sách này sau đó được đưa vào chuỗi, sử dụng hợp đồng phân tách của 0xSplit. Sau đó, các nhà tài trợ có thể gửi tiền trực tiếp đến địa chỉ của người nhận hoặc đến một hợp đồng trao quyền phát hành tiền đến địa chỉ của người nhận.
Báo cáo tạm thời thí điểm được tóm tắt trong tweet này. Dưới đây là một số điểm nổi bật
Chương trình thí điểm đã huy động được 9,7 triệu đô la từ các tổ chức như Lido, Uniswap, ENS, NounsDAO và MolochDAO, cũng như một số cá nhân thường xuyên quyên góp (cảm ơn Tetranode!) - cảm ơn tất cả các bạn đã biến điều này thành hiện thực!
PG có 90 thành viên khi ra mắt và hiện có 128, với 5 triệu đô la được phân phối giữa họ
Trung bình, mỗi thành viên nhận được 39.000 đô la, với mức thấp là 13.000 đô la và mức cao là 79.000 đô la
Kiến trúc của PG đang thay đổi, sẽ hỗ trợ L2 và loại bỏ nhu cầu đa chữ ký để cập nhật trọng số
Những kết quả ban đầu này cho thấy rằng PG đang hoạt động theo đúng kế hoạch: một cơ chế phân phối một rổ mã thông báo cho một nhóm người đóng góp giao thức đang phát triển, tự ươm tạo. Dự án này sẽ không có được ngày hôm nay nếu không có sự hỗ trợ hào phóng của các nhà tài trợ thí điểm.
Nhìn về phía trước, bây giờ là lúc để mở rộng phạm vi tiếp cận của PG và nhận ra tiềm năng đầy đủ của nó: Bồi thường cạnh tranh, được điều chỉnh theo rủi ro cho những người duy trì Ethereum. Điều dễ dàng nhất để làm ở đây là quyên góp cho PG ngay từ đầu dự án, như Danny Ryan đã nói trong tweet bắt đầu PG.
Hầu hết các khoản đóng góp trong thí điểm đến từ các dự án lớn hơn với nguồn tài trợ đáng kể. Nếu hiệp hội giao thức có thể thuyết phục các dự án này quyên góp cho PG ngay từ ngày đầu tiên, khi mã thông báo của họ vẫn thực sự "vô giá trị", thì những người duy trì Ethereum có thể hưởng lợi từ toàn bộ quỹ đạo đi lên của các dự án thành công này.
Khi có đủ dự án tham gia, các ưu đãi có thể giữ nhân tài tốt nhất trong thỏa thuận duy trì, thay vì kéo họ đi.
Để hỗ trợ điều này và nhiều hình thức quyên góp khác, PG sẽ cần một cuộc đại tu công nghệ. Phiên bản tiếp theo sẽ hỗ trợ L1 và L2, đồng thời giảm hơn nữa dấu ấn quản trị trên chuỗi của nó.
tiêu đề cấp đầu tiên
Theo sát
Điều đó kết thúc vào năm 2022... Thật là một năm phi thường! Ba tháng trước, chúng tôi thậm chí còn chưa hợp nhất! Giờ đây, Ethereum có Proof of Stake đang chạy âm thầm trong nền, trọng tâm đã chuyển sang các giao dịch trong tương lai.
Khi bạn trở lại vào tháng Giêng, bạn có thể mong đợi:
Shanghai/Capella Nâng cấp Testnet dành cho nhà phát triển và Shadow Fork
Lễ ra mắt KZG
Thảo luận xung quanh Cancun và quy trình nâng cấp mạng sẽ phát triển như thế nào để nắm bắt tốt hơn các sở thích của cộng đồng
Thử nghiệm của bang hội giao thức sẽ kết thúc và chúng tôi sẽ thông báo cấu trúc sau khi thử nghiệm
Cảm ơn vì đã đọc! Và cảm ơn tất cả những người đã dành thời gian để cải thiện Ethereum trong năm qua - chúng tôi đã đạt được rất nhiều.
liên kết gốc
IOS
Android