ethereum
Một hợp đồng tiếp tục chạy sau một lời gọi thất bại hiện không có cách đáng tin cậy nào để xác định liệu bên được gọi có đã hoàn tác có chủ ý hay đơn giản là hết gas do người gửi chọn. Khoảng trống này là gốc rễ của hành vi gây rối do thiếu gas, và một đề xuất bản nháp mới cố gắng khắc phục nó ở cấp độ EVM. EIP-8456, được mở để thảo luận trên Ethereum Magicians vào thứ Hai, thêm một lệnh gọi là CALLSTATUS, tạm thời ở opcode 0xA5 với 2 gas. Nó đẩy trạng thái hoàn thành của lệnh gọi hoặc tạo gần nhất trong khung hiện tại dưới dạng ba bit. Bit 0 có nghĩa là hoàn tác, bit 1 có nghĩa là dừng bất thường như hết gas, và bit 2 có nghĩa là có điều gì đó trong khung bên dưới đã dừng. Tác giả chỉ ra rằng bằng chứng duy nhất hiện nay là phép tính gasleft() sau lời gọi, và mọi phân nhánh điều chỉnh giá gas đều đã phá vỡ các ngưỡng đó. Giá gas hai chiều được đề xuất trong EIP-8037 sẽ làm cho phép tính này yếu hơn nữa, vì nguồn dự trữ của nó không thể nhìn thấy qua opcode GAS. Vậy tại sao lại cần bit thứ ba? Hầu hết các lời gọi thực tế đều đi qua các trung gian như proxy, bao bọc functionCall của OpenZeppelin, Multicall3 hoặc trình kiểm tra chữ ký ERC-1271. Nếu chỉ báo trạng thái kết thúc của bên được gọi trực tiếp, thì một bao bọc bắt dừng do hết gas và hoàn tác với lý do sẽ trông giống như một hoàn tác có chủ ý. Bản nháp giữ một cờ dính di chuyển lên mọi khung, để người gửi chỉ kiểm soát gas không bao giờ có thể khiến người gọi đọc được một hoàn tác đơn thuần. Nó báo cáo kết quả thay vì nguyên nhân, và bên được gọi vẫn có thể tạo ra sự dừng có chủ ý bằng INVALID. Nó chỉ bảo vệ mã được viết sau khi nó được triển khai, vì các hợp đồng đã triển khai sẽ không đọc nó. Chưa có đánh giá bên ngoài nào, số opcode vẫn đang mở, và một bản mẫu cùng các bài kiểm tra cho 58 trường hợp được liệt kê vẫn đang chờ thực hiện. Liên kết - https://t.co/KnByUBgWrY
Hầu hết các ví ethereum vẫn hiển thị toàn bộ lịch sử tài chính của bạn cho bất kỳ ai có địa chỉ của bạn, và Quỹ ethereum hiện đang coi đây là một lỗ hổng bảo mật thay vì một tính năng bảo mật tùy chọn. Vào thứ Hai, Quỹ đã đăng bài cho biết các cuộc tấn công và khai thác trong tuần qua đã làm rõ một điểm với họ: bảo mật và quyền riêng tư không thể được xem là những mục tiêu tách biệt. Họ nhấn mạnh rằng bạn sẽ ít lo lắng hơn về việc kẻ tấn công sử dụng lịch sử trên chuỗi của bạn chống lại bạn khi quyền riêng tư là mặc định. Bài đăng trích dẫn bản cập nhật về Kohaku, dự án công cụ ví ưu tiên quyền riêng tư của Quỹ. Kho lưu trữ JavaScript chia nhỏ thành các gói mà nhóm ví có thể tích hợp từng cái một. Có các thư viện cho Privacy Pools và Tornado Cash, cùng với thư viện Railgun mà README hiện đang ghi là đang được bảo trì. Một gói plugin định nghĩa giao diện chuẩn cho các giao thức hồ sơ ẩn, để ví có thể giao tiếp với tất cả chúng theo cùng một cách. Một gói provider trừu tượng hóa ethers, viem, Helios và Colibri. Kho lưu trữ cũng đi kèm một tài khoản ERC-4337 hậu lượng tử. Các crate Rust nằm trong kho lưu trữ chị em riêng biệt. Tôi thích cách đây được thiết kế như một SDK thay vì một ví quyền riêng tư khác yêu cầu người dùng chuyển tiền. Ý tưởng là các ví hiện có có thể thêm các luồng ẩn mà không cần mỗi nhóm phải triển khai lại ba giao thức. README rất rõ ràng về tình trạng hiện tại: Một số phần được ghi là chưa sẵn sàng cho sản xuất, và các gói chứa mã chưa được kiểm toán. Jordan Enev từ Ambire cho biết vào thứ Sáu tuần trước rằng nhóm đã dành nhiều tháng để kiểm thử các tích hợp, nhưng vẫn chưa có ngày ra mắt công khai nào được công bố. Vitalik và Nicolas Consigny dự kiến sẽ trình diễn Kohaku cùng Ambire trên mạng chính ethereum vào thứ Ba tới tại @EFDevcon, theo danh sách phiên họp. Đây là kho lưu trữ - https://t.co/egNbLgAo0J
Terminal của bạn hiện có thể phản hồi lại bạn, và điều thú vị là nó làm điều đó mà không cần gọi bất kỳ API đám mây nào. Vào thứ Bảy, Ollama đã phát hành phiên bản 0.40.11 với tính năng text-to-speech trên macOS. Mô hình giọng nói đầu tiên là Phonon, một họ các mô hình TTS nhỏ do Gradium phát triển. Bạn tải nó bằng lệnh ollama pull phonon và chạy nó như bất kỳ mô hình nào khác. Điểm mà các nhà phát triển thực sự quan tâm là API. Phonon hoạt động với endpoint /v1/audio/speech tương thích OpenAI trên localhost. Nếu mã của bạn đã sử dụng OpenAI SDK để xử lý giọng nói, tài liệu cho biết bạn chỉ cần thay đổi URL cơ sở mới. Phản hồi được truyền phát trong khi âm thanh đang được tạo, vì vậy phát lại có thể bắt đầu ngay khi chưa hoàn thành toàn bộ văn bản. Bạn thậm chí có thể chuyển trực tiếp phản hồi từ mô hình trò chuyện vào Phonon, và nó sẽ bắt đầu nói ngay sau câu đầu tiên. Đầu ra là âm thanh mono 24 kHz, mặc định dưới dạng WAV hoặc PCM 16-bit thô nếu bạn yêu cầu. Tài liệu liệt kê một số giới hạn dễ bị vượt quá. Mỗi yêu cầu có thể chứa tối đa 4.096 ký tự, mặc dù ollama run sẽ tự động chia nhỏ văn bản dài hơn cho bạn. Các ký tự, biểu tượng, email và URL được đọc từng chữ cái, trong khi ngày tháng dạng số được đọc nguyên dạng, do đó tài liệu khuyên nên viết ngày tháng dưới dạng chữ. Các tùy chọn không được hỗ trợ như tốc độ hoặc hướng dẫn sẽ trả về lỗi 400 thay vì bị bỏ qua lặng lẽ. Giấy phép cần được đọc kỹ trước khi triển khai bất kỳ sản phẩm nào. Mô hình Phonon tiếng Anh mặc định sử dụng giấy phép Apache 2.0. Các biến thể tiếng Pháp, Đức, Tây Ban Nha, Bồ Đào Nha và đa ngôn ngữ 40M sử dụng giấy phép CC BY-NC 4.0, cấm sử dụng thương mại. Ollama cũng cho biết trên MacBook Pro M5 Max, nó chạy nhanh hơn 35% so với runtime của chính Gradium — đây là kết quả do Gradium công bố chứ không phải đánh giá độc lập. Hiện tại, tính năng giọng nói chỉ hỗ trợ Apple Silicon, với hỗ trợ cho Windows và Linux được liệt kê là sẽ có trong thời gian tới.
Một L2 của Ethereum chấp nhận không có chữ ký nghe có vẻ như một lỗ hổng bảo mật, nhưng BB84 đang làm điều này có chủ đích để tránh các cuộc tấn công lượng tử. Cuối tuần trước, người sáng lập của nó, người đăng bài với tên Hadamard, đã công bố thiết kế trên Ethereum Research và yêu cầu phản hồi mang tính phê bình. BB84 là một rollup trên OP Stack trên mạng chính, đã hoạt động từ ngày 30 tháng Chín, nơi các giao dịch L2 hoàn toàn không sử dụng ECDSA. Mỗi tài khoản là đầu của một chuỗi hash keccak-256 được xây dựng từ một bí mật, với 1.000 bước theo mặc định. Để chi tiêu, ví của bạn sẽ tiết lộ giá trị trước đó trong chuỗi, và bất kỳ ai cũng có thể xác minh bằng cách băm một lần. Bên trong L2, giả định duy nhất còn lại là tính kháng preimage của keccak-256, mà thuật toán Grover làm giảm xuống khoảng 2^128 công việc. Việc tiết lộ bí mật khiến nó trở nên công khai, do đó giao thức thêm bước cam kết và tiết lộ để liên kết mỗi preimage với một giao dịch trước tiên. Hai loại giao dịch mới trong op-geth xử lý điều này, và kiểm tra người gửi thay thế ecrecover. Sự ủy quyền bị tiêu thụ ngay cả khi lệnh gọi bị hủy, và nếu ví bỏ lỡ bước gia hạn ở liên kết cuối cùng, địa chỉ đó sẽ bị vô hiệu. Bài đăng cũng nêu ra một lỗ hổng front-running mà nhóm đã phát hiện trong quá trình viết. Các cam kết không có chữ ký, nên trước đây một cam kết mới có thể thay thế cam kết đang chờ, và kẻ tấn công có thể liên kết lại bí mật đã tiết lộ với thanh toán của chính chúng. Một quy tắc có hiệu lực từ ngày 21 tháng Mười đã quy định cam kết đầu tiên sẽ chiến thắng. Các giới hạn được nêu rõ ràng. Việc nạp và rút trên L1 vẫn sử dụng ECDSA. Chưa có fault proofs, và theo chính bài đăng, chuỗi thậm chí còn chưa đạt đến Giai đoạn 0 của L2BEAT. Sequencer do nhóm vận hành, và các địa chỉ 160-bit mang lại khoảng 2^80 khả năng kháng lượng tử second-preimage. Bài đăng cũng đặt câu hỏi liệu các tài khoản chuỗi hash có thể trở thành EIP-7702 hoặc chế độ xác thực trừu tượng tài khoản bản địa trên các L2 tổng quát hay không.
OpenZeppelin đã chọn Chainlink làm tiêu chuẩn cho cross-chain và tuân thủ trong công cụ token của mình, và nếu bạn tích vào hộp tuân thủ, giấy phép của token của bạn sẽ thay đổi. Cách đây một tuần, OpenZeppelin đã công bố sự hợp tác chiến lược với Chainlink. CCIP và ACE, giao thức cross-chain và Automated Compliance Engine của Chainlink, hiện đã được tích hợp vào Contracts Wizard — công cụ AI và tài liệu của OpenZeppelin. Các trình tạo ERC20, Stablecoin và RWA đều cung cấp cả hai tùy chọn. Việc chọn tùy chọn CCIP sẽ mở ra các lệnh mint và burn mà một pool burn-and-mint của Chainlink cần, thông qua các quyền của chính token. Nó cũng chỉ định một quản trị viên để đăng ký CCIP. Phần này giữ nguyên giấy phép bạn đã chọn, vì không có mã Chainlink nào được đưa vào. Tùy chọn ACE thì khác biệt. Nó chuyển các giao dịch, mint và burn đến một Policy Engine mà bạn triển khai và cấu hình. Tài liệu chính thức của OpenZeppelin cho biết các token sử dụng ACE sẽ chịu sự ràng buộc của BUSL-1.1, và việc sử dụng trong môi trường sản xuất phải đáp ứng giấy phép ACE cùng các quyền sử dụng bổ sung của nó. Trong nhiều năm, một token được tạo bởi OpenZeppelin luôn mang theo giấy phép bạn chọn, thường là MIT. Bây giờ, chỉ một hộp kiểm duy nhất đã thay đổi điều đó, và một lập trình viên cấp dưới vội vàng có thể không bao giờ nhận ra. Trình tạo không đăng ký pool của bạn, không thiết lập quyền hoặc viết các chính sách của bạn. Việc gắn một Policy Engine không tự động cấu hình bất kỳ chính sách nào, và bạn vẫn chịu trách nhiệm tuân thủ mọi quy tắc áp dụng cho bạn. Thông báo cũng đề cập đến lộ trình di chuyển từ OpenZeppelin Defender sang Chainlink's Runtime Environment. Không có gì trong số này bị giấu kín, và đối với nhóm RWA đã muốn sử dụng Chainlink, nó giúp tiết kiệm đáng kể công việc tích hợp. Tôi chỉ mong các nhà phát triển chọn nó một cách chủ động, chứ không phải vì trình hướng dẫn đã đặt nó ở đó.
Các chuyên gia hợp đồng thông minh, Trình biên dịch Solidity của bạn có thể đã xóa lặng lẽ một phép ghi giá trị mà bạn cần, và bạn sẽ không bao giờ thấy điều đó trong mã nguồn. Solidity 0.8.38 đã được phát hành vào thứ Năm tuần trước. Nó sửa một lỗi trong trình tối ưu hóa Yul, lỗi này tồn tại trong mọi phiên bản từ 0.8.19 đến 0.8.37. Trình tối ưu hóa ghi lại các ghi chú về những gì đang có trong bộ nhớ và lưu trữ. Nó sử dụng những ghi chú này để thay thế một phép tải bằng giá trị mà nó đã biết, và bỏ qua một phép ghi nếu giá trị cần ghi đã tồn tại. Để xác định xem hai địa chỉ có thể chồng lấn hay không, nó mô tả mỗi địa chỉ dưới dạng biến cơ sở cộng với độ lệch. Cùng biến cơ sở, độ lệch khác nhau, vậy chúng phải là các ô khác nhau. Những mô tả này được lưu vào bộ nhớ đệm. Sau đó, ai đó gán lại biến cơ sở. Trình tối ưu hóa không luôn nhận ra điều đó. Bây giờ nó so sánh một địa chỉ được xây dựng từ giá trị cũ với một địa chỉ được xây dựng từ giá trị mới, như thể chúng chia sẻ cùng một biến cơ sở. Nó kết luận rằng chúng khác nhau, nhưng ở thời điểm chạy, chúng lại trỏ đến cùng một vị trí. Kết quả là một ghi chú lỗi thời. Một phép tải sau đó có thể trả về giá trị cũ. Một phép ghi mà bạn cần có thể bị xóa bỏ. Một hàm keccak256 trên vị trí đó có thể băm dữ liệu lỗi thời. Chỉ mã được biên dịch với trình tối ưu hóa bật mới bị ảnh hưởng. Với via-IR, bất kỳ mã nào cũng có thể gặp lỗi này, ngay cả khi không dùng inline assembly. Với pipeline truyền thống mặc định, chỉ một số inline assembly và các hàm trợ giúp do trình biên dịch tạo ra. Các bản dựng không tối ưu hóa thì an toàn. Đội ngũ đánh giá mức độ nghiêm trọng thấp, và họ đã làm điều mà tôi mong muốn mọi đội ngũ trình biên dịch đều làm: Họ đã biên dịch lại tất cả các hợp đồng đã xác minh trong cơ sở dữ liệu Sourcify với và không có bản sửa lỗi, và bytecode của tất cả chúng đều giống nhau. Vì vậy, lỗi này rất hiếm. Hiếm không có nghĩa là không bao giờ xảy ra, đặc biệt nếu mã của bạn mới và chưa được triển khai. Lỗi này được phát hiện thông qua chương trình bounty của Ethereum Foundation, và một báo cáo thứ hai cho thấy mã Solidity thuần không dùng assembly cũng có thể kích hoạt nó.
Khát khao nam tính trở thành ETH maxi. 🥳
Ethereum là Ethereum và sẽ mãi là như vậy. Trong phân nhánh tiếp theo, cộng đồng Ethereum sẽ chứng kiến phép màu thực sự của giao thức.