gakonst

Xử lý khối Ethereum nhanh hơn 15-20% trên Reth v1.5.0.

còn nhiều hơn nữa sắp tới!

không rõ tại sao điều này có thể là một quan điểm không phổ biến về CT, nhưng: tôi nghĩ rằng xe tải uniswap thật tuyệt vời.

Nếu bạn là kỹ sư Reth và bạn đang làm việc với các nhà tuyển dụng, hãy thoải mái liên hệ trực tiếp với tôi.

Chúng tôi đã tạo ra vai trò Kỹ sư Reth như một trong những vai trò quan trọng nhất cho tương lai của cơ sở hạ tầng crypto, và chúng tôi có rất nhiều vai trò trong danh mục. Tôi sẽ giới thiệu cho bạn.

Bạn có thể tạo ra một stablecoin từ các hợp đồng phái sinh hashrate bitcoin không?

Người dùng không nên trả phí gas, các ứng dụng nên làm điều đó.

Ví dụ NextJS cho việc tài trợ phí ở Porto vừa được gửi đến (liên kết trong chủ đề)

Cập nhật Frontiers bởi @Paradigm! 6-8 tháng 8 tại SF.

Ngày thứ 2 trông thật 🔥🔥🔥 .

Không 1, không 2, mà là 3 bài nói về hiệu suất cao!
- "Tối ưu hóa cực độ Reth" bởi @ashekhirin & @Rjected
- “Mở rộng State Trie của Ethereum” bởi @brianisbland
- "Mở rộng Ethereum L1" bởi @adietrichs.

Đăng ký bên dưới!

Giải pháp gập / IVC SNARK nhanh nhất hiện nay là gì?

Nó có một triển khai tối ưu hóa không?

Vẫn đang tìm kiếm một chuyên gia đồng thuận về các công cụ xác nhận dựa trên cổ phần cho các chuỗi khối bằng chứng công việc, điểm cộng nếu bạn đã nghiên cứu về bằng chứng công việc hữu ích / cấu trúc thị trường MEV v.v.

thật tuyệt nếu biểu đồ xã hội crypto của tôi giữ được tính kỹ thuật khi mọi thứ đang diễn ra trên thế giới hoặc mắc kẹt với những quan điểm dân chủ và hòa bình, chỉ cần tốt hơn vì crypto được cho là công nghệ cho tự do toàn cầu và hòa bình

Những điều cuối cùng sẽ không giúp Ethereum chiến thắng ở Glamsterdam: EOF, EVM64, SSZ/pureth, Các Chứng nhận Có sẵn.

Cần một cuộc tấn công mạnh mẽ, không phải tấn công yếu, và chắc chắn không phải phòng thủ dài hạn vào lúc này. Phòng thủ ngắn hạn (ví dụ như định giá lại) thì tốt.

RE: cái gì nên xảy ra với EL của Ethereum, quan điểm hiện tại của tôi là:
- Fusaka ghi điểm với những thắng lợi dễ dàng và đặt giới hạn cho việc tăng giới hạn gas.
- Glamsterdam tiếp tục tăng giới hạn gas như trên trong khi định giá lại để giới hạn các kết quả tồi tệ nhất.

Góc nhìn điên rồ của tôi có thể là sau Glamsterdam, ngoài việc định giá lại và tăng giới hạn gas, chúng ta cần chuyển sang tối ưu hóa EL cho việc sử dụng ZK, bất kể điều đó có nghĩa là gì.

Fusaka sẽ diễn ra trong năm nay và cho phép các L2 mở rộng hơn nữa.

Blobs sẽ vẫn giữ nguyên khi ra mắt, và với các nhánh blob đã được lên lịch trước, chúng tôi hy vọng sẽ đạt tới 48 vào khoảng Q1'26.

Chúng tôi sẽ tiếp tục đo lường và xem chúng tôi có thể đạt được bao xa, các công cụ đã sẵn sàng, chỉ còn lại là thực hiện.

Chúng tôi đang trở nên tốt hơn trong việc sử dụng AI để cải thiện năng suất của mình và trao quyền cho cộng đồng mã nguồn mở.

Trong PR này, chúng tôi chia sẻ các lời nhắc mà Claude đã thành công trong việc xây dựng một công cụ kiểm tra EVM call cấp thấp cho Forge Lint (chạy theo mặc định trên forge build)

https://github.com/foundry-rs/foundry/pull/10810

Những gì tôi nghĩ là quan trọng để Ethereum chiến thắng trong khi duy trì một tập hợp nút toàn cầu:

1. tách biệt xác thực khỏi việc xây dựng khối bằng cách sử dụng zk. Điều này cần làm cho việc chứng minh zk khối theo thời gian thực dễ dàng hơn: ePBS hoặc Thực thi trì hoãn, tôi không quan tâm cái nào. Việc chuyển đổi trie có ích nhưng theo ý kiến của tôi là không cần thiết, trong khi đảm bảo rằng bạn không chứng minh vào cuối khe thời gian mà là ở đầu thực sự quan trọng.

2. tách biệt khả năng chống kiểm duyệt khỏi nút yếu nhất. Nếu bạn làm như trên, việc giới thiệu các nút với ETH đặt cọc thấp w FOCIL, những người chỉ chịu trách nhiệm cho CR nhưng không phải cho việc xây dựng khối và xác thực đường nóng, giải phóng chúng tôi khỏi việc sử dụng raspberry pi để mở rộng nhưng cho phép chúng tôi tiếp tục sử dụng raspberry pi cho CR.

Những gì tôi nghĩ là quan trọng để Ethereum chiến thắng trong khi duy trì một tập hợp nút toàn cầu:

1. tách biệt xác thực khỏi xây dựng khối với zk. điều này cần làm cho việc chứng minh zk trong thời gian thực dễ dàng hơn: ePBS hoặc Thực Thi Trì Hoãn, tôi không quan tâm cái nào. di chuyển trie giúp nhưng theo ý kiến của tôi không cần thiết, trong khi đảm bảo rằng bạn không chứng minh vào cuối phiên mà vào đầu thật sự quan trọng.

2. tách biệt khả năng chống kiểm duyệt khỏi nút yếu nhất. Nếu bạn làm điều trên, việc giới thiệu các nút được đặt cọc ETH thấp chỉ chịu trách nhiệm cho CR nhưng không cho xây dựng và xác thực khối đường nóng sẽ giải phóng chúng ta khỏi các raspberry pi để mở rộng nhưng cho phép chúng ta tiếp tục sử dụng raspberry pi cho CR.

Tôi vẫn còn bối rối rằng cộng đồng Ethereum Core Dev không ưu tiên sửa chữa 2 vấn đề được nhắc đến nhiều nhất của các nhà phát triển EVM theo khảo sát Solidity Lang mặc dù chúng tôi đã nỗ lực nhiều lần:

1. Ngăn xếp quá sâu: vâng, đây là một vấn đề kỹ năng của Solidity một chút nhưng chỉ cần thêm một phạm vi opcode SWAP/DUP17-32 và gọi đó là xong. Bạn sẽ tiêu tốn một số opcode. Không sao, chúng được thiết kế để sử dụng. Bạn sẽ gặp một sự không phù hợp kiểu PUSH0 khác, điều này cũng không sao, nó không hoàn hảo nhưng cũng được.

2. Dỡ bỏ giới hạn 24KB. Tôi thực sự không quan tâm bạn làm gì, hãy làm nó thành 32KB, 48KB, 128KB, 256KB, 512KB, làm tất cả một lần, từng bước một, tính phí hay không nhưng hãy làm điều gì đó! Ngay bây giờ, không phải năm sau!

Nếu bạn đang mở rộng L1, đảm bảo mọi người có thể viết hợp đồng mà không gặp lỗi ngớ ngẩn là P0.

Nếu hệ thống không thể xử lý thêm 8KB cho mỗi bytecode mà đây là tham số đã được thiết lập cách đây 10 năm thì sẽ không có cơ hội nào để bạn thực sự mở rộng L1.

Sửa chữa ngăn xếp quá sâu và giới hạn kích thước bytecode! Đối với các nhà phát triển!

Tôi vẫn còn bối rối rằng cộng đồng Ethereum Core Dev không ưu tiên sửa chữa 2 vấn đề được trích dẫn nhiều nhất của các nhà phát triển EVM theo khảo sát Solidity Lang:

1. Stack quá sâu: vâng, đây là một vấn đề kỹ năng của Solidity một chút nhưng chỉ cần thêm một phạm vi mã lệnh SWAP/DUP17-32 và gọi đó là một ngày. Bạn sẽ đốt cháy một số mã lệnh. Không sao, chúng được tạo ra để sử dụng. Bạn sẽ gặp một sự không khớp kiểu PUSH0 khác, điều này cũng không sao, nó không hoàn hảo nhưng cũng không sao.

2. Dỡ bỏ giới hạn 24KB. Tôi không thực sự quan tâm bạn làm gì, hãy làm cho nó thành 32KB, 48KB, 128KB, 256KB, 512KB, làm tất cả cùng một lúc, dần dần, định giá hay không nhưng hãy làm điều gì đó! Bây giờ, không phải năm sau!

Nếu bạn đang mở rộng L1, đảm bảo mọi người có thể viết hợp đồng mà không gặp lỗi ngu ngốc là P0.

Nếu hệ thống không thể xử lý thêm 8KB cho mỗi bytecode, đây là một tham số đã được thiết lập cách đây 10 năm, thì không có cơ hội nào bạn có thể thực sự mở rộng L1.

Sửa lỗi stack quá sâu và giới hạn kích thước bytecode! Đối với các nhà phát triển!

Tôi vẫn còn bối rối rằng cộng đồng Ethereum Core Dev không ưu tiên sửa chữa vấn đề được trích dẫn nhiều nhất của các nhà phát triển EVM theo khảo sát Solidity Lang

1. Ngăn quá sâu: đúng vậy, đây là một vấn đề kỹ năng Solidity một chút nhưng chỉ cần thêm một phạm vi opcode SWAP/DUP17-32 và gọi đó là xong. Bạn sẽ đốt một số opcode. Không sao, chúng được thiết kế để được sử dụng. Bạn sẽ gặp một sự không khớp kiểu PUSH0 khác, điều này cũng không sao, nó không hoàn hảo nhưng cũng không sao.

2. Nâng giới hạn 24KB. Tôi không thực sự quan tâm bạn làm gì, hãy làm cho nó 32KB, 48KB, 128KB, 256KB, 512KB, làm tất cả cùng một lúc, dần dần, định giá nó hoặc không nhưng hãy làm gì đó! Bây giờ, không phải năm sau!

Nếu bạn đang mở rộng L1, việc đảm bảo mọi người có thể viết hợp đồng mà không gặp lỗi ngu ngốc là P0.

Nếu hệ thống không thể xử lý thêm 8KB cho mỗi bytecode mà đó là một tham số đã được đặt 10 năm trước thì sẽ không có cơ hội nào để bạn thực sự mở rộng L1.

Sửa lỗi ngăn quá sâu và giới hạn kích thước bytecode! Đối với các nhà phát triển!

Mỗi phần của cơ sở hạ tầng crypto sẽ liên quan đến Reth theo cách này hay cách khác.

Điều quan trọng nhất cho sự thành công của nó là cộng đồng OSS. Một nhóm được đào tạo gồm hơn 500 người phân phối địa lý đã đóng góp cho Reth và đã mua vào tầm nhìn và thành công lâu dài của nó.

Ở cấp độ kỹ thuật, dự án Reth có 3 trụ cột:
- An ninh: Chúng tôi đạt được điều đó bằng cách hỗ trợ Ethereum L1 trong các môi trường staking sản xuất. Có mặt trong trò chơi.
- Hiệu suất: Chúng tôi đạt được điều đó bằng cách đẩy ranh giới trên L2s và xây dựng Block MEV. Terragas.
- Tính mở rộng: Chúng tôi cung cấp các API xuất sắc để sửa đổi nút của bạn mà không cần phải fork. Reth SDK.

Còn rất nhiều điều để làm, nhưng thật sự tự hào về nơi chúng tôi đang ở hôm nay.