Hiểu biết sâu về cơ chế xử lý giao dịch của Ethereum

lời tựa

tiêu đề cấp đầu tiên"lời tựa"、"Chuỗi khối là một"phi tập trung"không tin tưởng"Một sổ cái phân tán được duy trì chung bằng cách"phân phối"sổ cái

Chuỗi khối đương nhiên là không thể thiếu đối với sổ sách kế toán và các giao dịch đương nhiên trở thành ưu tiên hàng đầu. Biết rằng Phòng thí nghiệm bảo mật chuỗi khối Chuangyu sẽ phân tích ngắn gọn thiết kế logic của cấu trúc dữ liệu nhóm giao dịch Ethereum, thiết lập phí giao dịch, xây dựng giao dịch, tổng hợp giao dịch, chữ ký giao dịch, xác minh giao dịch, v.v. từ góc độ mã nguồn và thông qua giao dịch Fang thiết kế cơ chế bảo mật để nghiên cứu thiết kế cơ chế bảo mật chuỗi công khai.

tiêu đề cấp đầu tiên

Khái niệm cơ bản

Sơ đồ của quy trình giao dịch đại khái như sau:
Mô tả dòng chảy:

• Đầu tiên, người dùng bắt đầu một yêu cầu giao dịch thông qua mạng, ký giao dịch bằng khóa riêng của mình, sau đó truyền phát giao dịch, sau đó thêm giao dịch vào nhóm giao dịch. đóng gói nó và tạo ra Các khối sau đó được tạo thông qua sự đồng thuận và cuối cùng các khối giao dịch được phát ra toàn bộ mạng.
  Dòng dữ liệu:
  Nguồn dữ liệu của nhóm giao dịch:

• Đồng bộ hóa từ xa, thông qua hình thức đồng bộ hóa quảng bá, dữ liệu giao dịch của các nút Ethereum khác được đồng bộ hóa với nút cục bộ.

Vị trí của dữ liệu trong nhóm giao dịch: được người khai thác (thợ mỏ) thu thập và xác minh, được sử dụng để khai thác, được ghi vào khối sau khi khai thác thành công và phát sóng, giao dịch sẽ bị xóa khỏi nhóm giao dịch sau khi được ghi vào chuẩn chuỗi, nếu giao dịch được viết Sau khi vào ngã ba, các giao dịch trong nhóm giao dịch sẽ không bị giảm, sau đó chờ đóng gói lại.

tiêu đề cấp đầu tiên

cấu trúc dữ liệu

Cấu hình mặc định như sau:

Cấu trúc dữ liệu TxPool như sau:

tiêu đề cấp đầu tiên

Khi phân tích thực thi giao dịch, trước tiên chúng ta cần xem xét một số cấu hình cơ bản, chẳng hạn như: có giới hạn trên/giới hạn dưới tối đa cho phí giao dịch hay không, cấu hình nhóm giao dịch, số lần truy xuất thông tin giao dịch tối đa, v.v. Ở đây chúng ta chỉ xem xét một số điểm chính:

tiêu đề phụ

02 Cấu hình nhóm giao dịch

tiêu đề phụ

03 Số lượng truy xuất giao dịch

Khởi tạo nhóm

Việc khởi tạo nhóm giao dịch được thực hiện thông qua NewTxPool và mã cụ thể như sau:

Tại đây, chức năng sanitize được gọi trước tiên để xác minh các thông số cấu hình nhằm tránh việc đặt giá gas vô lý.

Sau đó, khởi tạo nhóm giao dịch ( txpool ) với cấu hình mặc định:

Sau đó, khởi tạo tài khoản cục bộ và thêm địa chỉ tài khoản cục bộ đã định cấu hình vào nhóm giao dịch:

Sau đó, tạo một giao dịch theo thứ tự gasprices:

Code triển khai cụ thể như sau:

Sau đó, gọi đặt lại để cập nhật nhóm giao dịch:

Việc thực hiện đặt lại cụ thể như sau:

Sau đó bắt đầu vòng lặp tổ chức lại để nó có thể xử lý các yêu cầu được tạo trong quá trình tải nhật ký:

Mã triển khai cụ thể của scheduleReorgLoop được hiển thị bên dưới. Chức năng này chủ yếu được sử dụng cho kế hoạch thực hiện đặt lại và quảng báExecutable.

Sau đó đăng ký các sự kiện giao dịch có liên quan và bắt đầu vòng lặp chính:

Mã triển khai cụ thể của vòng lặp chính như sau. Nó là một goroutine của txPool và cũng là vòng lặp sự kiện chính. Nó chủ yếu được sử dụng để chờ và phản hồi các sự kiện chuỗi khối bên ngoài cũng như các báo cáo khác nhau và các sự kiện thu hồi giao dịch:

tiêu đề cấp đầu tiên

xây dựng giao dịch

• Giao dịch được bắt đầu bởi người dùng, để tài sản được chuyển từ bên này sang bên kia, được gọi là chuyển giá trị. Cấu trúc giao dịch trực quan nhất của chúng tôi là chuyển tiền qua ví. Ở đây chúng tôi trực tiếp sử dụng RPC của eth_sendTransaction làm ví dụ để phân tích quá trình xây dựng giao dịch, ví dụ về yêu cầu eth_sendTransaction như sau:

• Thông số ví dụ:

• từ: DATA, 20 byte - địa chỉ nguồn của giao dịch gửi

• đến: DATA, 20 byte - địa chỉ đích của giao dịch, tùy chọn khi tạo hợp đồng mới

• gas: SỐ LƯỢNG - lượng gas khả dụng để thực hiện giao dịch, số nguyên tùy chọn, giá trị mặc định 90000, gas không sử dụng sẽ được trả lại

• gasPrice: QUANTITY - giá gas, tùy chọn, mặc định: Được xác định

• giá trị: SỐ LƯỢNG - số tiền được gửi bởi giao dịch, một số nguyên tùy chọn

dữ liệu: DATA - chữ ký và tham số mã hóa của quá trình biên dịch hợp đồng hoặc phương thức được gọi

nonce: SỐ LƯỢNG - nonce, tùy chọn, cùng một nonce có thể được sử dụng để viết lại các giao dịch đang chờ xử lý

Phản hồi ví dụ:"Hãy theo dõi quá trình thực thi của eth_sendTransaction, một RPC. Tại đây, trước tiên hãy kiểm tra xem tài khoản có tồn tại không, sau đó kiểm tra xem Nonce có trống không, sau đó gọi SingTx để thực hiện thao tác chữ ký, sau đó gọi SubmitTransaction để gửi giao dịch:"Mã triển khai của SignTx như sau, trong đó SignTx sẽ tiếp tục được gọi cho các hoạt động chữ ký, vì vậy tôi sẽ không đi vào chi tiết ở đây và phần tiếp theo

chữ ký giao dịch

Một phân tích chi tiết sẽ được thực hiện:"Ký xong quay lại SendTransaction gọi SubmitTransaction để gửi chữ ký, tại đây đầu tiên nó sẽ kiểm tra phí giao dịch có đủ không, sau đó gọi SendTx để gửi giao dịch:"Quá trình triển khai SendTx cụ thể như sau, tại đây AddLocal sẽ được gọi để thêm giao dịch vào nhóm giao dịch, sẽ không có thêm chi tiết tại đây.

Mô-đun đơn vị phân tích này:

Sau đó kiểm tra xem địa chỉ nhận có trống không, nếu trống, hãy tạo một địa chỉ (thường xuất hiện khi hợp đồng được tạo), sau đó in nhật ký có đầy đủ chi tiết TX để điều tra và phân tích thủ công tiếp theo, sau đó trả về giá trị băm của giao dịch:

tiêu đề cấp đầu tiên

Giao dịch vào pool

Chúng tôi biết rằng có hai nguồn giao dịch: một nguồn được gửi cục bộ và nguồn kia được gửi từ xa. Mã triển khai cụ thể của hai nguồn này lần lượt là AddLocals và AddRemotes. Hai chức năng này được sử dụng khi thêm giao dịch vào nhóm giao dịch. Đây là đạt được bằng cách gọi addTxs:

Mã addTxs trông như thế này:

Đầu tiên, giao dịch sẽ được lọc để kiểm tra xem đó có phải là giao dịch đã biết (nghĩa là đã thêm hoặc phát), sau đó gọi hàm gửi để xác minh địa chỉ được lấy từ chữ ký (v, r, s) thông qua đường cong elip secp256k1 , nếu có nguồn gốc Nếu không thành công hoặc được ký không chính xác, nó sẽ trả về lỗi:

Sau đó thêm giao dịch vào nhóm giao dịch (lưu ý: có khóa giao dịch ở đây)

Việc triển khai cụ thể addTxsLocked như sau, nó sẽ xếp hàng đợi các giao dịch hợp lệ và gọi hàm pool.add để thêm giao dịch vào hàng đợi giao dịch:

Việc triển khai cụ thể chức năng add như sau:

Tại đây, trước tiên, nó sẽ kiểm tra xem giao dịch hiện tại đã được biết chưa (nghĩa là nó đã được phát hoặc thêm vào nhóm) và nếu đã biết, nó sẽ bị loại bỏ trực tiếp:

Sau đó, xác định xem giao dịch được gửi cục bộ hay từ xa và gọi hàm validateTx để xác minh giao dịch. Nếu xác minh không thành công, nó sẽ bị hủy trực tiếp:

Sau đó kiểm tra xem nhóm giao dịch đã đầy chưa và nếu đã đầy, hãy loại bỏ các giao dịch bị định giá thấp trong hàng đợi giao dịch.

Sau đó, đánh giá xem có giao dịch nào có cùng giá trị nonce trong hàng chờ xử lý của giao dịch hiện tại hay không. Nếu có, hãy đánh giá xem giá gas do trao đổi hiện tại đặt có vượt quá tỷ lệ phần trăm PriceBump đã đặt hay không. Nếu vượt quá, hãy thay thế và ghi đè lên giao dịch hiện có . Nếu không, một lỗi sẽ được trả về và Gasprice của giao dịch thay thế quá thấp và ném nó vào hàng đợi ( enqueueTx ):

Sau khi gọi enqueueTx, nó sẽ được thêm vào hàng đợi giao dịch, đồng thời, kiểm tra xem tài khoản từ có phải là địa chỉ cục bộ hay không và nếu có, hãy thêm nó vào địa chỉ cục bộ của nhóm giao dịch:

Mã enqueueTx như sau, chức năng này chủ yếu chèn các giao dịch mới vào hàng đợi giao dịch:

Cuối cùng, nó sẽ chuyển đến hàm addTx, trong đó hàm requestPromoteExecutables sẽ được gọi để thực hiện thao tác yêu cầu xúc tiến giao dịch, thao tác này chủ yếu đưa giao dịch từ hàng đợi sang trạng thái chờ xử lý:

chữ ký giao dịch

Chữ ký giao dịch chủ yếu được thực hiện bởi chức năng SignTx, trước tiên hãy kiểm tra xem ví đã đóng chưa, sau đó kiểm tra xem tài khoản ví có chứa tài khoản của yêu cầu giao dịch động dục hay không, sau đó gọi SignTx để xử lý chữ ký:

Mã triển khai cụ thể của SignTx như sau:

Sử dụng ECDSA (Thuật toán mã hóa đường cong Elliptic) để đăng nhập và sau đó trả lại kết quả đã ký:

xác minh giao dịch

tiêu đề cấp đầu tiên

• xác minh giao dịch

• Xác minh giao dịch là phần quan trọng nhất trong toàn bộ liên kết giao dịch. Đối với người dùng, xác minh giao dịch là một phương tiện quan trọng để đảm bảo an toàn cho tài sản của người dùng. Đối với toàn bộ Ethereum, xác minh giao dịch là một cách quan trọng để đảm bảo hoạt động ổn định và phát triển bền vững của Ethereum. , xác minh giao dịch chủ yếu xảy ra trong các trường hợp sau:

• Khi người dùng hoàn thành chữ ký của một giao dịch, anh ta cần gửi giao dịch đến mạng chuỗi khối để giao dịch có thể được xác nhận càng sớm càng tốt và nút cần xác minh giao dịch trước khi gửi giao dịch để xác nhận tính hợp pháp của sự giao dịch;

• Khi một nút nhận được giao dịch được phát bởi các nút khác, nút đó cần xác minh xem giao dịch đó có hợp pháp hay không và giao dịch hợp pháp sẽ được thêm vào nhóm giao dịch của nút;

Khi một nút nhận được một khối được đồng bộ hóa bởi các nút khác, nó cũng cần xác minh các giao dịch có trong khối.

Quá trình xác minh giao dịch được hoàn thành bởi hàm validateTx và mã logic của nó như sau. Tại đây, nó sẽ kiểm tra xem eip2718 có được bật hay không và loại giao dịch, sau đó kiểm tra kích thước của giao dịch, số lượng chuyển giao dịch, gas của giao dịch, tính chính xác của chữ ký giao dịch và đảm bảo giao dịch Thực hiện theo thứ tự Nonce, liệu tài sản của thương nhân có đủ hay không và đảm bảo giá khí giao dịch. Phí giao dịch cơ bản cao:

tiêu đề cấp đầu tiên

nâng cấp giao dịch

Nâng cấp giao dịch chủ yếu đề cập đến việc đưa giao dịch vào danh sách đang chờ xử lý. Sự khác biệt giữa phương thức này và phương thức thêm là chức năng thêm sẽ chèn giao dịch mới thu được vào danh sách đang chờ xử lý, trong khi PromoteExecutables đặt tệp thực thi vào danh sách địa chỉ tài khoản đã cho. được chèn vào danh sách hàng đợi đang chờ xử lý và giao dịch không hợp lệ được kiểm tra, sau đó sự kiện cập nhật nhóm giao dịch được gửi. Mã triển khai như sau:

Ở đây, một vòng lặp for được sử dụng để lặp lại tất cả các tài khoản và nâng cấp các giao dịch.Ở đây, trước tiên, tất cả các giao dịch trong hàng đợi có nonce thấp hơn nonce hiện tại của tài khoản sẽ bị xóa:

Sau đó, xóa tất cả các giao dịch trong hàng đợi có mức tiêu thụ lớn hơn số dư trong tài khoản hoặc có gas lớn hơn giới hạn gas tối đa:

Sau đó, thêm tất cả các giao dịch có thể thực thi từ hàng đợi vào trạng thái chờ xử lý, trong đó phương thức promoteTx sẽ được gọi để đưa các giao dịch ( Txs ) trong hàng đợi vào trạng thái chờ xử lý:

Mã triển khai của promoteTx như sau. Chức năng này trước tiên chèn giao dịch vào hàng chờ xử lý. Nếu giao dịch cũ tốt hơn (giao dịch Gasprice lớn hơn hoặc bằng 110% giá trị giao dịch ban đầu, tiêu chuẩn liên quan đến pricebump setting), sau đó xóa giao dịch hiện tại. Giao dịch này, nếu giao dịch hiện tại tốt hơn giao dịch cũ thì xóa giao dịch cũ, sau đó cập nhật danh sách:

Sau đó, quay lại hàm promoteExecutables và nếu hàng đợi tài khoản không cục bộ nhỏ hơn giới hạn ( AccountQueue ), hãy xóa nó:

Cuối cùng, ghi lại mục đã xóa và cập nhật queuedGauge. Nếu giao dịch của tài khoản này trong hàng đợi trống, hãy xóa tài khoản này:

• hạ cấp giao dịch

• Hạ cấp giao dịch có nghĩa là khi một khối mới xuất hiện, giao dịch được đóng gói sẽ bị hạ cấp từ phần đệm xuống hàng đợi hoặc khi giá Gas của một giao dịch khác cao hơn, nó sẽ bị hạ cấp từ phần đệm xuống hàng đợi. chức năng triển khai là demoteUnexecutables và việc hạ cấp giao dịch chủ yếu xảy ra trong ba trường hợp sau:

• Phân nhánh dẫn đến giảm giá trị Nonce của Tài khoản: Nếu số giao dịch m trên chuỗi chính tắc ban đầu A có giá 20 và đã có trên chuỗi, nhưng số giao dịch m trên chuỗi chính tắc mới không có trên chuỗi sau fork, dẫn đến số giao dịch m được ghi trên chuỗi chuẩn Nonce của tài khoản bị giảm, do đó giao dịch m phải được quay trở lại nhóm giao dịch và được đặt trong hàng đợi;

Ngã ba làm cho giá trị nonce của giao dịch đang chờ xử lý khác với giá trị nonce của trạng thái.

Mã của demoteUnexecutables như sau.Ở đây, trước tiên, giá trị Nonce mới nhất của mỗi addr thu được bằng cách duyệt qua danh sách đang chờ xử lý, sau đó giao dịch có Nonce nhỏ hơn giá trị Nonce thu được từ truy vấn trước đó sẽ bị xóa, sau đó số dư tài khoản không đủ để thanh toán phí giao dịch và một số giao dịch tạm thời không hợp lệ được trả lại. việc hạ cấp trên được thực hiện, nếu không có giao dịch nào trong một addr nào đó đang chờ xử lý, giao dịch sẽ bị xóa Tài khoản cần xóa:

tiêu đề cấp đầu tiên

thiết lập lại hồ bơi

Chúng ta có thể thiết lập lại nhóm giao dịch thông qua thiết lập lại, mã cụ thể của phương pháp này như sau:

Nếu phần đầu cũ không phải là null, quá trình sắp xếp lại bắt đầu. Tại thời điểm này, nếu khối đầu của chuỗi cũ lớn hơn chiều cao của khối đầu của chuỗi mới, thì chuỗi cũ sẽ khôi phục và tái chế tất cả các giao dịch đã khôi phục. Nếu khối đầu của chuỗi mới Nếu nó lớn hơn khối đầu của chuỗi cũ, thì chuỗi mới sẽ lùi lại và tái chế giao dịch. Khi chuỗi mới và chuỗi cũ đạt cùng độ cao, chúng sẽ lùi lại tại đồng thời cho đến khi chúng tìm thấy một nút cha chung, sau đó tìm ra tất cả các giao dịch được lưu trữ trong giá trị loại bỏ nhưng không được bao gồm, rồi chèn lại các giao dịch này vào nhóm:

Sau đó đặt trạng thái thế giới mới nhất, đặt trạng thái của khối đầu chuỗi mới, sau đó đặt giao dịch được hỗ trợ bởi chuỗi cũ vào nhóm giao dịch:

tiêu đề cấp đầu tiên"Tóm tắt ở cuối bài viết"Chuỗi khối bao gồm các khối được liên kết với nhau theo cấu trúc chuỗi. Mỗi khối bao gồm hai phần: phần đầu khối và phần thân khối. Phần thân khối lưu trữ các bản ghi giao dịch, vì vậy

Bài viết này phân tích các mô-đun chức năng như cấu trúc dữ liệu nhóm giao dịch Ethereum, thiết lập phí giao dịch, xây dựng giao dịch, chữ ký giao dịch, mục nhập nhóm giao dịch, xác minh giao dịch, nâng cấp giao dịch, hạ cấp giao dịch, đặt lại nhóm giao dịch, v.v. từ góc độ mã nguồn. quy trình và thiết kế bảo mật của xử lý giao dịch Ethereum đã được khám phá, nhưng việc xây dựng hệ thống bảo mật chuỗi công cộng vẫn còn một chặng đường dài phía trước và cần được khám phá thêm.

Liên kết tham khảo:

https://blog.csdn.net/lj900911/article/details/84825739 

https://blog.csdn.net/pulong074