Hàm băm thân thiện với STARK

Hàm băm thân thiện với STARK là gì?

Hàm băm thân thiện với STARK là hàm băm mật mã được thiết kế để hoạt động hiệu quả trong các hệ thống chứng minh STARK và những môi trường chứng minh không kiến thức đại số khác.

Trong crypto, hàm băm được dùng để nén dữ liệu thành đầu ra có kích thước cố định, xây dựng cây Merkle, tạo cam kết, tạo định danh, kiểm tra tính toàn vẹn và hỗ trợ nhiều quy trình bảo mật blockchain.

Hàm băm thân thiện với STARK thực hiện cùng chức năng chung như hàm băm thông thường, nhưng được xây dựng để hoạt động hiệu quả trên các trường hữu hạn và các ràng buộc đa thức.

Điều này quan trọng vì chứng minh STARK biểu diễn tính toán thông qua các mệnh đề đại số mà prover phải chứng minh và verifier phải kiểm tra.

Nếu một hàm băm khó biểu diễn dưới dạng các ràng buộc đại số đơn giản, việc chứng minh số lượng lớn hàm băm sẽ chậm và tốn kém.

Các hàm băm truyền thống như SHA-256 và Keccak rất hiệu quả cho phần mềm thông thường và cơ chế đồng thuận blockchain, nhưng có thể tốn kém khi dùng trong nhiều mạch chứng minh không kiến thức hoặc quá trình số học hóa STARK.

Vì vậy, hàm băm thân thiện với STARK được tối ưu cho việc tạo chứng minh, thay vì chỉ tối ưu hiệu năng CPU.

Trang công nghệ STARK chính thức của StarkWare mô tả chứng minh STARK là các chứng minh chỉ có thể được tạo bởi một prover off-chain thực sự đã thực thi phép tính với các đầu vào phụ trợ cần thiết.

Vì chứng minh tính toán là chi phí cốt lõi, hàm băm được sử dụng trong quá trình tính toán đó phải được lựa chọn cẩn thận.

Nói đơn giản, hàm băm thân thiện với STARK là hàm băm dễ chứng minh hơn, rẻ hơn và nhanh hơn trong các hệ thống blockchain dựa trên STARK.

Vì sao hàm băm thân thiện với STARK quan trọng?

Hàm băm thân thiện với STARK quan trọng vì các hệ thống không kiến thức thường cần băm lượng dữ liệu rất lớn.

Một rollup có thể băm dữ liệu giao dịch, cập nhật tài khoản, cam kết trạng thái, đường dẫn Merkle, thông điệp và đầu vào chứng minh.

Một giao thức riêng tư có thể băm note, nullifier, cam kết, bí mật và lá cây Merkle.

Lớp thực thi blockchain có thể băm các trường giao dịch, lệnh gọi hợp đồng, khóa lưu trữ và dữ liệu tài khoản.

Nếu mỗi lần băm cần nhiều ràng buộc đại số, chứng minh sẽ nặng hơn.

Một chứng minh nặng hơn có thể làm tăng thời gian của prover, mức sử dụng bộ nhớ, chi phí và độ trễ của người dùng.

Bài báo về hàm băm Poseidon cho biết Poseidon được thiết kế cho các hệ thống chứng minh không kiến thức và trong các bối cảnh mà tác giả phân tích, có thể dùng ít ràng buộc trên mỗi bit thông điệp hơn đáng kể so với hàm băm Pedersen.

Loại cải thiện hiệu quả này quan trọng vì việc băm thường được lặp lại hàng nghìn hoặc hàng triệu lần trong các ứng dụng cần nhiều chứng minh.

Đối với người dùng crypto, lựa chọn hàm băm tốt hơn có thể gián tiếp đồng nghĩa với giao dịch rẻ hơn, tạo chứng minh nhanh hơn, chi phí hạ tầng thấp hơn và ứng dụng có khả năng mở rộng tốt hơn.

Đối với nhà phát triển, băm thân thiện với STARK là một trong những lựa chọn thiết kế quan trọng nhất trong kiến trúc ứng dụng ZK.

STARK nghĩa là gì?

STARK là viết tắt của Scalable Transparent Argument of Knowledge.

Chứng minh STARK cho phép prover chứng minh rằng một phép tính đã được thực hiện chính xác mà không cần verifier chạy lại toàn bộ phép tính.

Từ scalable đề cập đến mục tiêu chứng minh hiệu quả các phép tính quy mô lớn.

Từ transparent có nghĩa hệ thống chứng minh không phụ thuộc vào nghi thức thiết lập đáng tin cậy như một số hệ thống chứng minh khác.

Từ argument nghĩa là hệ thống cung cấp bảo đảm mật mã mạnh theo các giả định đã nêu.

Cụm từ of knowledge nghĩa là prover chứng minh mình biết dữ liệu hoặc phép tính thỏa mãn mệnh đề.

Trong các hệ thống blockchain, STARK thường được dùng cho validity rollup, tính toán có thể xác minh, hệ thống riêng tư và thực thi có khả năng mở rộng.

Trang web chính thức của Starknet mô tả Starknet là một validity rollup sử dụng công nghệ STARK để xác thực bằng mật mã các giao dịch off-chain.

Hàm băm xuất hiện liên tục trong các hệ thống này vì cam kết và cây Merkle là những khối xây dựng cốt lõi.

Đó là lý do hàm băm thân thiện với STARK không phải chi tiết kỹ thuật nhỏ, mà là phần cốt lõi của kỹ thuật chứng minh có khả năng mở rộng.

Cách hoạt động của hàm băm thân thiện với STARK

Hàm băm thân thiện với STARK thường hoạt động trên trường hữu hạn, thay vì chỉ xử lý dữ liệu dưới dạng byte và phép toán bit.

Trường hữu hạn là một tập hợp toán học mà phép cộng, trừ, nhân và chia hoạt động theo các quy tắc số học mô-đun.

Các hệ thống chứng minh STARK được xây dựng tự nhiên xoay quanh trường hữu hạn và ràng buộc đa thức.

Hàm băm sử dụng phép cộng trường, phép nhân, lũy thừa đơn giản và các lớp tuyến tính có thể dễ chứng minh hơn hàm băm dựa trên xoay bit, logic Boolean và các phép toán cấp byte.

Nhiều hàm băm thân thiện với STARK dùng thiết kế dựa trên hoán vị.

Hàm băm dựa trên hoán vị liên tục biến đổi một trạng thái qua các vòng thao tác phi tuyến và tuyến tính.

Lớp phi tuyến cung cấp khả năng chống lại các tấn công đại số và vi sai.

Lớp tuyến tính phân tán các thay đổi trên toàn bộ trạng thái nội bộ.

Đầu ra cuối cùng được lấy từ một phần trạng thái đã biến đổi.

Mục tiêu thiết kế là duy trì độ mạnh mật mã của hàm băm, đồng thời khiến mỗi vòng có chi phí biểu diễn thấp trong hệ thống chứng minh.

Hàm băm thân thiện với STARK so với hàm băm thông thường

Hàm băm thông thường thường được tối ưu cho tốc độ phần mềm, tốc độ phần cứng, phân tích bảo mật và khả năng tương thích rộng.

Hàm băm thân thiện với STARK được tối ưu để tạo chứng minh hiệu quả trong các hệ thống chứng minh đại số.

SHA-256 là hàm băm mạnh và được sử dụng rộng rãi, nhưng các phép toán bit của nó có thể tốn kém khi biểu diễn trong nhiều mạch số học.

Keccak được dùng phổ biến trong blockchain, nhưng phép hoán vị cấp bit của nó cũng có thể tốn kém trong các hệ thống chứng minh ưu tiên số học trường.

Hàm băm thân thiện với STARK tránh nhiều phép toán bit tốn kém đó.

Nó sử dụng các thao tác phù hợp với trường gốc của hệ thống chứng minh.

Điều này không có nghĩa các hàm băm thông thường là kém.

Điều đó chỉ có nghĩa chúng được thiết kế cho các môi trường khác nhau.

Đối với chữ ký blockchain thông thường, mã định danh giao dịch hoặc khả năng tương thích với giao thức hiện có, hàm băm truyền thống vẫn có thể cần thiết.

Đối với mạch ZK nội bộ, cây Merkle và cam kết gốc cho chứng minh, hàm băm thân thiện với STARK có thể hiệu quả hơn nhiều.

Hàm băm thân thiện với STARK so với hàm băm thân thiện với ZK

Hàm băm thân thiện với STARK là một loại hàm băm thân thiện với ZK.

Hàm băm thân thiện với ZK là danh mục rộng hơn gồm các hàm băm được thiết kế cho hệ thống chứng minh không kiến thức.

Hàm băm thân thiện với STARK tập trung vào hiệu quả trong quá trình số học hóa kiểu STARK, như AIR hoặc các hệ thống ràng buộc đa thức liên quan.

Một số hàm băm được thiết kế cho mạch SNARK, mạch STARK, hệ thống kiểu PLONK, R1CS hoặc nhiều hệ thống chứng minh cùng lúc.

Lựa chọn hàm băm tốt nhất phụ thuộc vào hệ thống chứng minh, trường hữu hạn, ngôn ngữ mạch, mức bảo mật, chi phí chứng minh và môi trường triển khai.

Một hàm băm hiệu quả trong hệ thống chứng minh này có thể không phải lựa chọn tốt nhất trong hệ thống khác.

Ví dụ, một hàm băm được tối ưu cho SNARK trường nguyên tố có thể không lý tưởng cho STARK trường nhị phân.

Vì vậy, nhà phát triển không nên xem “thân thiện với ZK” là nhãn mang tính phổ quát.

Câu hỏi chính xác hơn là liệu hàm băm có hiệu quả và an toàn đối với đúng hệ thống chứng minh đang dùng hay không.

Hàm băm thân thiện với STARK là thân thiện với ZK theo cách riêng của STARK.

Vì sao SHA-256 và Keccak có thể tốn kém trong STARK?

SHA-256 và Keccak không được thiết kế chủ yếu cho các hệ thống chứng minh đại số.

SHA-256 sử dụng nhiều phép toán bit, gồm xoay, dịch, XOR và hàm Boolean.

Keccak cũng sử dụng các thao tác cấp bit trong phép hoán vị sponge của nó.

Các thao tác này hiệu quả trên máy tính thông thường vì bộ xử lý xử lý bit và byte một cách tự nhiên.

Tuy nhiên, prover STARK thường làm việc với phần tử trường và ràng buộc đa thức.

Biểu diễn từng phép toán bit trong ràng buộc trường có thể cần nhiều bước bổ sung.

Các bước bổ sung đó làm tăng khối lượng công việc của prover và độ phức tạp của hệ thống chứng minh.

Đây là lý do hàm băm thân thiện với STARK cố gắng sử dụng trực tiếp các thao tác đại số phù hợp với hệ thống chứng minh.

Trong một số trường hợp, hàm băm truyền thống vẫn cần thiết để tương thích với chain, bridge hoặc định dạng địa chỉ hiện có.

Trong nhiều quy trình chứng minh nội bộ, hàm băm thân thiện với STARK có thể là lựa chọn kỹ thuật tốt hơn.

Hàm băm Poseidon

Poseidon là một trong những hàm băm thân thiện với ZK được thảo luận rộng rãi nhất.

Nó được thiết kế để hoạt động hiệu quả trên các trường hữu hạn và giảm số ràng buộc cần thiết trong hệ thống chứng minh.

Trang trình bày Poseidon của USENIX Security mô tả Poseidon là hàm băm hoạt động gốc với các đối tượng trường hữu hạn và được thiết kế cho hệ thống chứng minh không kiến thức.

Poseidon sử dụng cấu trúc giống sponge dựa trên hoán vị đại số.

Nó áp dụng các thao tác S-box phi tuyến và lớp trộn tuyến tính qua nhiều vòng.

Ưu điểm chính là nó có thể rẻ hơn rất nhiều để chứng minh so với các hàm băm hướng byte truyền thống trong nhiều môi trường ZK.

Poseidon thường được dùng cho cây Merkle, cam kết, nullifier và băm nội bộ trong các ứng dụng cần nhiều chứng minh.

Trong bối cảnh Starknet và Cairo, Poseidon quan trọng vì được khuyến nghị cho nhiều chương trình Cairo nhờ hiệu quả chứng minh.

Phần Cairo book về làm việc với hàm băm chính thức cho biết Poseidon rẻ hơn và nhanh hơn Pedersen khi làm việc với hệ thống chứng minh STARK, đồng thời hiện là hàm băm được khuyến nghị cho các chương trình Cairo.

Điều này khiến Poseidon trở thành ví dụ trung tâm về hàm băm thân thiện với STARK trong phát triển blockchain thực tế.

Hàm băm Pedersen

Hàm băm Pedersen là một hàm băm quan trọng khác trong lịch sử STARK và Starknet.

Pedersen hashing dựa trên các thao tác đường cong elliptic và đã được sử dụng trong nhiều hệ thống mật mã.

Tài liệu mật mã Starknet chính thức liệt kê hàm băm Pedersen là một trong các hàm băm được sử dụng trong thông số kỹ thuật Starknet.

Trong quá khứ, Starknet đã dùng hàm băm Pedersen tại những vị trí quan trọng, bao gồm hành vi ánh xạ lưu trữ legacy và các thành phần hệ thống cũ.

Cairo book chính thức giải thích rằng Pedersen là hàm băm đầu tiên được sử dụng trên Starknet và vẫn được dùng trong một số bối cảnh liên quan đến lưu trữ legacy.

Pedersen có thể an toàn và hữu ích, nhưng có thể kém hiệu quả hơn Poseidon đối với nhiều khối lượng công việc chứng minh STARK.

Đó là lý do phát triển Cairo mới thường ưu tiên Poseidon khi khả năng tương thích không yêu cầu Pedersen.

Pedersen vẫn quan trọng vì hợp đồng, địa chỉ và cơ chế lưu trữ cũ có thể phụ thuộc vào nó.

Nhà phát triển cần biết hàm băm nào được yêu cầu trong từng bối cảnh.

Dùng sai hàm băm có thể tạo ra địa chỉ không chính xác, truy vấn lưu trữ lỗi, chữ ký không hợp lệ hoặc chứng minh thất bại.

Hàm băm Rescue

Rescue là một thiết kế hàm băm khác được xây dựng để sử dụng hiệu quả trong các hệ thống chứng minh đại số.

Giống Poseidon, Rescue được thiết kế xoay quanh thao tác trường hữu hạn thay vì logic cấp bit.

Các hàm băm kiểu Rescue sử dụng hoán vị đại số với lớp phi tuyến và trộn tuyến tính được lựa chọn cẩn thận.

Mục tiêu là cung cấp bảo mật mật mã mạnh đồng thời giữ số ràng buộc chứng minh ở mức thấp.

Rescue thường được thảo luận trong cùng nhóm hàm băm định hướng số học hóa với Poseidon, Griffin, Anemoi và các thiết kế thân thiện với ZK hiện đại khác.

Nó có thể phù hợp với một số hệ thống chứng minh tùy thuộc vào triển khai, tham số và giả định bảo mật.

Tuy nhiên, thân thiện với STARK không tự động có nghĩa một hàm băm nên được dùng ở mọi nơi.

Nhà phát triển nên kiểm tra liệu hàm băm có triển khai trưởng thành, tham số đã được audit, hỗ trợ hệ sinh thái và thực hành phân tách miền rõ ràng hay không.

Poseidon đã trở nên đặc biệt phổ biến trong nhiều hệ sinh thái ZK, nhưng Rescue vẫn quan trọng như một phần của không gian thiết kế rộng hơn.

Sự tồn tại của nhiều hàm băm thân thiện với STARK cho thấy lĩnh vực này vẫn đang phát triển tích cực.

Các hàm băm của Starknet

Starknet sử dụng một số hàm băm cho các nhu cầu giao thức và ứng dụng khác nhau.

Tài liệu mật mã Starknet chính thức mô tả Starknet Keccak, hàm băm Pedersen và hàm băm Poseidon là các hàm băm được sử dụng xuyên suốt thông số kỹ thuật Starknet.

Starknet Keccak là phiên bản Keccak riêng của Starknet, ánh xạ đầu ra vào trường STARK.

Pedersen đã được sử dụng trong các bối cảnh legacy và vẫn là một phần trong một số hành vi của Starknet.

Poseidon được sử dụng trong các phép tính hash giao dịch mới hơn và được khuyến nghị trong nhiều bối cảnh lập trình Cairo.

Tài liệu tham chiếu trường giao dịch và phép tính hash giao dịch Starknet cho thấy hash giao dịch v3 được tính bằng Poseidon trên các phần tử giao dịch.

Điều này quan trọng vì lựa chọn hàm băm không chỉ mang tính lý thuyết.

Nó ảnh hưởng trực tiếp đến mã định danh giao dịch, khóa lưu trữ, chữ ký, hành vi hợp đồng và hiệu năng chứng minh.

Nhà phát triển xây dựng trên Starknet phải tuân theo hàm băm được yêu cầu bởi thành phần giao thức cụ thể.

Người dùng không cần biết mọi chi tiết, nhưng nên hiểu rằng các hàm băm khác nhau có thể phục vụ các vai trò khác nhau trong cùng hệ sinh thái.

Trường hữu hạn

Trường hữu hạn là nền tảng toán học của nhiều hàm băm thân thiện với STARK.

Một trường hữu hạn chứa số lượng phần tử có giới hạn và hỗ trợ các phép toán số học vẫn nằm trong trường đó.

Hệ thống chứng minh STARK sử dụng trường hữu hạn vì đồng nhất thức đa thức, miền đánh giá và ràng buộc đại số có thể được biểu diễn tự nhiên trên chúng.

Hàm băm thân thiện với STARK hoạt động tốt khi các thao tác nội bộ là cộng trường, nhân, lũy thừa và trộn kiểu ma trận.

Các thao tác này có thể được biểu diễn trực tiếp hơn trong hệ thống chứng minh so với thao tác bit.

Đây là một lý do hàm băm gốc trường thường hiệu quả hơn cho chứng minh ZK.

Tuy nhiên, thiết kế trường hữu hạn cũng đặt ra các câu hỏi về tham số.

Hàm băm phải an toàn trên trường được chọn.

Số mũ S-box, hằng số vòng, độ rộng trạng thái và số vòng phải được chọn cẩn thận.

Hàm băm thân thiện với STARK không chỉ là “băm bằng toán học”, mà là thiết kế mật mã được tinh chỉnh cho một môi trường đại số cụ thể.

Số học hóa

Số học hóa là quá trình chuyển đổi tính toán thành các ràng buộc đại số mà hệ thống chứng minh có thể chứng minh.

Trong STARK, phép tính có thể được biểu diễn dưới dạng execution trace và được kiểm tra bằng các ràng buộc đa thức.

Một hàm băm thân thiện với số học hóa có thể được biểu diễn bằng tương đối ít ràng buộc đơn giản.

Đây là lý do chính khiến các hàm băm thân thiện với STARK tồn tại.

Nếu hàm băm cần nhiều ràng buộc cho mỗi vòng hoặc mỗi bit đầu vào, mọi đường dẫn Merkle và cam kết sẽ trở nên tốn kém.

Nếu hàm băm sử dụng thao tác gốc trường, quá trình số học hóa có thể nhỏ hơn nhiều.

Số học hóa nhỏ hơn có thể giảm thời gian prover, mức sử dụng bộ nhớ và chi phí tạo chứng minh.

Nó cũng có thể giúp ứng dụng dùng cây Merkle sâu hơn hoặc batch lớn hơn.

Đối với nhà phát triển, hiểu số học hóa giúp lý giải vì sao hàm băm tốt nhất cho phần mềm thông thường có thể không phải hàm băm tốt nhất trong một chứng minh.

Hàm băm thân thiện với STARK tốt nhất là hàm phù hợp với cấu trúc đại số của hệ thống chứng minh trong khi vẫn duy trì bảo mật mật mã.

Cây Merkle và hàm băm thân thiện với STARK

Cây Merkle là một trong những nơi phổ biến nhất mà hàm băm thân thiện với STARK xuất hiện.

Cây Merkle băm dữ liệu thành các lá, sau đó liên tục băm từng cặp hoặc nhóm node cho đến khi tạo ra một root.

Merkle root được dùng cho cam kết trạng thái, chứng minh bao gồm, batch rollup, note riêng tư, danh sách airdrop và nhiều quy trình crypto khác.

Nếu hệ thống chứng minh phải xác minh đường dẫn Merkle, nó có thể cần chứng minh nhiều thao tác băm.

Một cây Merkle sâu có thể cần hàng chục phép tính băm cho một chứng minh.

Một hệ thống rollup hoặc riêng tư có thể xác minh nhiều đường dẫn Merkle trong một batch.

Điều này khiến hàm băm trở thành yếu tố chi phí lớn.

Dùng hàm băm thân thiện với STARK có thể làm cho việc xác minh chứng minh Merkle trong STARK rẻ hơn đáng kể.

Điều này có thể hỗ trợ cây trạng thái lớn hơn, tạo chứng minh nhanh hơn và chi phí ứng dụng thấp hơn.

Đối với hệ thống ZK, cây Merkle thường chỉ thực tế tương ứng với mức độ thực tế của hàm băm bên trong nó.

Cam kết và nullifier

Các hệ thống crypto tập trung vào quyền riêng tư thường sử dụng cam kết và nullifier.

Cam kết che giấu một giá trị bí mật nhưng vẫn ràng buộc người dùng với giá trị đó.

Nullifier ngăn chi tiêu kép bằng cách tiết lộ một thẻ duy nhất khi note riêng tư được chi tiêu.

Cả cam kết lẫn nullifier thường phụ thuộc vào hàm băm.

Nếu các hàm băm đó được chứng minh trong STARK, hàm băm thân thiện với STARK có thể giảm chi phí chứng minh.

Ví dụ, người dùng có thể chứng minh họ biết một note bí mật có cam kết nằm trong cây Merkle mà không tiết lộ chính note đó.

Chứng minh có thể cần băm note, tính nullifier và xác minh đường dẫn Merkle.

Mỗi bước này đều có thể bao gồm thao tác băm.

Hàm băm gốc cho chứng minh có thể giúp giao dịch riêng tư hiệu quả hơn.

Đây là lý do hàm băm thân thiện với STARK không chỉ quan trọng đối với khả năng mở rộng mà còn với các ứng dụng quyền riêng tư thực tế.

Phân tách miền

Phân tách miền là việc sử dụng các nhãn, tiền tố, hằng số hoặc cấu trúc đầu vào khác nhau để cùng một hàm băm có thể được dùng an toàn trong các ngữ cảnh khác nhau.

Điều này quan trọng vì hàm băm dùng cho node cây Merkle không nên vô tình có ý nghĩa trùng với hàm băm dùng cho giao dịch, nullifier, thông điệp chữ ký hoặc khóa lưu trữ.

Phân tách miền giúp ngăn sự nhầm lẫn giữa các giao thức.

Với hàm băm thân thiện với STARK, phân tách miền có thể được xây dựng bằng tiền tố, hằng số, dung lượng sponge, mã hóa có kiểu hoặc quy tắc riêng của giao thức.

Nhà phát triển không nên chỉ nối các phần tử trường mà không hiểu cách mã hóa được kỳ vọng.

Mã hóa mơ hồ có thể tạo va chạm ở cấp ứng dụng ngay cả khi bản thân hàm băm mạnh.

Ví dụ, băm hai giá trị dưới dạng một cặp không được nhầm lẫn với băm một danh sách dài hơn.

Phân tách miền tốt giúp hệ thống chứng minh an toàn hơn và dễ audit hơn.

Hàm băm cung cấp độ mạnh mật mã, nhưng giao thức phải sử dụng nó đúng cách.

Nhiều lỗi ZK bắt nguồn từ mã hóa dữ liệu kém thay vì primitive băm bị hỏng.

Yêu cầu bảo mật

Hàm băm thân thiện với STARK vẫn cần những thuộc tính bảo mật mật mã thông thường.

Nó phải chống được tấn công preimage, khi kẻ tấn công cố tìm đầu vào khớp với đầu ra đã biết.

Nó phải chống được tấn công second-preimage, khi kẻ tấn công cố tìm đầu vào khác có cùng đầu ra với đầu vào đã biết.

Nó phải chống được tấn công va chạm, khi kẻ tấn công cố tìm bất kỳ hai đầu vào khác nhau nào có cùng đầu ra.

Nó cũng phải chống được các tấn công đại số có thể liên quan hơn với thiết kế hàm băm dựa trên trường.

Chỉ hiệu quả là chưa đủ.

Một hàm băm rẻ để chứng minh nhưng yếu trước phân tích mật mã là nguy hiểm.

Bảo mật phụ thuộc vào số vòng, lựa chọn S-box, kích thước trường, tạo tham số, tính chính xác của triển khai và phân tách miền.

Nhà phát triển nên dùng các tham số đã được đánh giá kỹ và tránh tự tạo cấu hình hàm băm tùy chỉnh khi chưa có chuyên gia xem xét.

Trong mật mã học, thay đổi nhỏ về tham số có thể tạo ra vấn đề bảo mật lớn.

Lựa chọn tham số

Lựa chọn tham số là một trong những phần khó nhất khi thiết kế hàm băm thân thiện với STARK.

Tham số có thể bao gồm độ rộng trạng thái, rate, capacity, số vòng, số mũ S-box, ma trận MDS, hằng số vòng và lựa chọn trường.

Những lựa chọn này ảnh hưởng đến bảo mật và hiệu năng.

Nhiều vòng hơn có thể cải thiện bảo mật nhưng làm tăng chi phí chứng minh.

Ít vòng hơn có thể cải thiện tốc độ nhưng làm suy yếu biên độ an toàn.

Trạng thái rộng hơn có thể hấp thụ nhiều dữ liệu hơn trong mỗi hoán vị nhưng cần nhiều thao tác hơn trong mỗi vòng.

Trường khác có thể thay đổi những số mũ nào hiệu quả hoặc an toàn.

Hằng số vòng cần được tạo một cách minh bạch và có thể tái lập khi có thể.

Triển khai phải khớp chính xác với bộ tham số chính thức hoặc đã được audit.

Hàm băm thân thiện với STARK chỉ đáng tin cậy tương ứng với tham số và triển khai được dùng trong môi trường production.

Hàm băm thân thiện với STARK và Cairo

Cairo là ngôn ngữ lập trình dùng cho tính toán dựa trên STARK và hợp đồng thông minh Starknet.

Hàm băm trong Cairo quan trọng vì chúng ảnh hưởng đến lưu trữ hợp đồng, dữ liệu giao dịch, chữ ký và hiệu quả chứng minh.

Cairo book chính thức giải thích rằng Poseidon hiện được khuyến nghị cho chương trình Cairo vì rẻ hơn và nhanh hơn Pedersen khi làm việc với chứng minh STARK.

Khuyến nghị này phản ánh mục tiêu thực tế đằng sau việc băm thân thiện với STARK.

Nhà phát triển không chọn Poseidon chỉ vì nó thịnh hành.

Họ chọn nó vì phù hợp hơn với số học của hệ thống chứng minh.

Tuy nhiên, nhà phát triển Cairo vẫn có thể cần Pedersen hoặc Keccak trong những bối cảnh giao thức cụ thể.

Ví dụ, khả năng tương thích với lưu trữ legacy hoặc dữ liệu bên ngoài theo kiểu Ethereum có thể yêu cầu một hàm băm cụ thể.

Một nhà phát triển Cairo giỏi cần biết hàm băm nào phù hợp với mục đích nào.

Dùng hàm băm hiệu quả nhất sai chỗ vẫn có thể làm hỏng ứng dụng.

Hàm băm thân thiện với STARK và hash giao dịch

Hash giao dịch xác định giao dịch và cam kết các trường giao dịch quan trọng.

Trên Starknet, các định dạng hash giao dịch mới hơn có thể dùng Poseidon trên các phần tử trường.

Tài liệu tham chiếu giao dịch Starknet chính thức cho thấy hash giao dịch v3 dùng Poseidon trên các trường như phiên bản, địa chỉ người gửi, giới hạn gas, chain ID, nonce, hash calldata và dữ liệu liên quan.

Đây là ví dụ về hàm băm thân thiện với STARK được dùng trong quy trình giao thức cốt lõi.

Hash giao dịch phải mang tính xác định.

Mọi node và ví phải tính cùng một hash từ cùng các trường dữ liệu.

Nếu ví ký một hash nhưng mạng xác minh một hash khác, giao dịch sẽ thất bại.

Điều này có nghĩa thông số kỹ thuật hash phải chính xác.

Nhà phát triển nên tuân theo công thức hash giao dịch chính thức thay vì tự xây dựng lối tắt.

Băm ở cấp giao thức không phải lĩnh vực để phỏng đoán.

Hàm băm thân thiện với STARK và khóa lưu trữ

Khóa lưu trữ là một lĩnh vực khác mà hàm băm quan trọng.

Lưu trữ hợp đồng thông minh thường dùng khóa đã băm để ánh xạ biến, địa chỉ và chỉ mục tới vị trí lưu trữ.

Trong lịch sử Starknet, Pedersen đã được sử dụng cho một số hành vi ánh xạ lưu trữ.

Cairo book lưu ý rằng LegacyMap sử dụng Pedersen để băm khóa cho các ánh xạ lưu trữ trên Starknet.

Mã ứng dụng mới hơn có thể ưu tiên Poseidon khi được hỗ trợ và khuyến nghị.

Điều này tạo ra vấn đề tương thích cho nhà phát triển.

Bố cục lưu trữ cũ phải tiếp tục dùng hàm băm được kỳ vọng để đọc đúng dữ liệu.

Thay đổi hàm băm lưu trữ có thể thay đổi nơi giá trị được lưu.

Nếu xử lý không đúng, điều này có thể khiến số dư, phê duyệt hoặc giá trị cấu hình cũ không thể truy cập.

Băm lưu trữ phải được xem là một phần trong bố cục dữ liệu vĩnh viễn của ứng dụng.

Hàm băm thân thiện với STARK và rollup

Rollup dùng hàm băm để cam kết batch, giao dịch, cập nhật trạng thái, thông điệp và chứng minh.

Một validity rollup dựa trên STARK có thể hưởng lợi từ hàm băm thân thiện với STARK vì tính toán cần nhiều thao tác băm trở nên rẻ hơn để chứng minh.

Trang StarkWare Starknet chính thức mô tả Starknet là Layer 2 tạo chứng minh STARK off-chain và gửi các chứng minh đó on-chain.

Trong một hệ thống như vậy, công việc chứng minh off-chain là phần lớn chi phí vận hành.

Nếu hash nội bộ không hiệu quả, prover phải thực hiện nhiều công việc hơn cho mỗi batch.

Nếu hash nội bộ hiệu quả, hệ thống có thể xử lý nhiều dữ liệu hơn với chi phí chứng minh thấp hơn.

Điều này có thể cải thiện khả năng mở rộng cho người dùng dù họ không bao giờ trực tiếp thấy hàm băm.

Người dùng rollup thường quan tâm phí và tốc độ.

Ở tầng bên dưới, các kết quả người dùng nhìn thấy phụ thuộc một phần vào hiệu quả của hệ thống chứng minh.

Hàm băm thân thiện với STARK là một trong những khối xây dựng giúp validity rollup thông lượng cao trở nên thực tế hơn.

Hàm băm thân thiện với STARK và trừu tượng hóa tài khoản

Trừu tượng hóa tài khoản cho phép tài khoản sử dụng logic xác thực linh hoạt thay vì chỉ mô hình chữ ký cố định.

Hàm băm xuất hiện trong trừu tượng hóa tài khoản vì tài khoản có thể băm dữ liệu giao dịch, chữ ký, session key, quy tắc chính sách hoặc thông điệp xác thực.

Trên chain dựa trên STARK, logic xác thực tài khoản phải được chứng minh như một phần của quá trình thực thi.

Nếu mã tài khoản thực hiện nhiều thao tác băm tốn kém, chi phí chứng minh có thể tăng.

Hàm băm thân thiện với STARK có thể giúp xác thực tài khoản hiệu quả hơn khi giao thức hỗ trợ.

Tuy nhiên, trừu tượng hóa tài khoản cũng có thể cần tương thích với lược đồ chữ ký hoặc định dạng thông điệp bên ngoài.

Điều đó nghĩa là nhà phát triển đôi khi có thể cần cả hàm băm thân thiện với STARK lẫn hàm băm truyền thống trong cùng hệ thống tài khoản.

Thiết kế đúng phụ thuộc vào tiêu chuẩn ví, xác minh chữ ký, khả năng tương thích bridge và an toàn người dùng.

Băm hiệu quả hữu ích, nhưng bảo mật tài khoản vẫn phải là ưu tiên hàng đầu.

Hàm băm rẻ không hữu ích nếu nó làm suy yếu phân tách miền chữ ký hoặc ủy quyền giao dịch.

Hàm băm thân thiện với STARK và bridge

Bridge thường xác minh thông điệp, state root, chứng minh lưu trữ hoặc đầu ra rollup trên các chain khác nhau.

Khả năng tương thích hash trở nên quan trọng khi một phía bridge dùng hàm băm thân thiện với STARK và phía còn lại dùng hàm băm truyền thống.

Ví dụ, hệ thống dựa trên STARK có thể dùng Poseidon nội bộ, trong khi chain khác có thể yêu cầu Keccak hoặc SHA-256 cho các chứng minh gốc của nó.

Bridge có thể cần chứng minh hoặc xác minh cả hai loại hàm băm.

Điều này có thể tăng chi phí vì hệ thống chứng minh có thể phải bao gồm hàm băm truyền thống tốn kém để đảm bảo tương thích.

Một số hệ thống dùng adapter, chứng minh đệ quy hoặc lớp cam kết riêng để xử lý vấn đề này.

Nhà phát triển bridge phải rất cẩn thận với các giả định về hash.

Không khớp về mã hóa trường, thứ tự byte, padding hoặc phân tách miền có thể làm hỏng quá trình xác minh.

Hàm băm thân thiện với STARK cải thiện hiệu quả nội bộ, nhưng hệ thống cross-chain vẫn cần tương thích chính xác với các giao thức bên ngoài.

Vì vậy, lựa chọn hàm băm vừa là vấn đề bảo mật bridge vừa là vấn đề hiệu năng.

Hàm băm thân thiện với STARK và xác minh chứng minh Merkle

Xác minh chứng minh Merkle thường là lý do chính để dùng hàm băm thân thiện với STARK.

Chứng minh Merkle cho thấy một lá thuộc về root của cây đã cam kết.

Để xác minh chứng minh trong STARK, prover phải tính từng hash trên đường dẫn.

Nếu cây sâu, chứng minh có thể cần nhiều hash lặp lại.

Nếu mỗi hash tốn kém, toàn bộ chứng minh sẽ tốn kém.

Các hàm băm kiểu Poseidon có thể giảm gánh nặng này trong nhiều hệ thống chứng minh dựa trên trường.

Điều này hỗ trợ các ứng dụng dùng cây Merkle cho cam kết trạng thái, allowlist, snapshot token, note riêng tư, thông điệp bridge và cam kết khả dụng dữ liệu.

Cây Merkle xây dựng bằng hàm băm thân thiện với STARK có thể hiệu quả trong chứng minh, nhưng có thể kém tương thích hơn với các hệ thống yêu cầu Merkle root dùng hàm băm truyền thống.

Nhà phát triển nên quyết định cây Merkle chủ yếu phục vụ chứng minh nội bộ hay khả năng tương thích bên ngoài.

Hàm băm tốt nhất phụ thuộc vào nơi và cách chứng minh sẽ được xác minh.

Hàm băm thân thiện với STARK và phần cứng

Thân thiện với STARK không phải lúc nào cũng đồng nghĩa nhanh nhất trên phần cứng thông thường.

Hàm băm truyền thống như SHA-256 có thể cực nhanh trên CPU, GPU, ASIC và thư viện tối ưu hóa.

Hàm băm gốc trường có thể chậm hơn trong phần mềm thông thường nhưng rẻ hơn trong hệ thống chứng minh.

Sự khác biệt này quan trọng khi benchmark.

Nhà phát triển không nên chỉ so sánh hàm băm bằng tốc độ phần mềm thô.

Họ nên so sánh thời gian prover, ràng buộc chứng minh, mức sử dụng bộ nhớ, chi phí xác minh, mức độ trưởng thành trong audit và khả năng tương thích.

Hàm băm có vẻ chậm hơn trong Rust, C++ hoặc JavaScript thuần vẫn có thể tốt hơn cho prover STARK.

Hàm băm nhanh trong chứng minh có thể không lý tưởng cho tính toàn vẹn dữ liệu đa dụng bên ngoài chứng minh.

Các môi trường khác nhau ưu tiên những thiết kế khác nhau.

Thân thiện với STARK nghĩa là thân thiện với chứng minh trước hết, không phải nhanh nhất một cách phổ quát trong mọi bối cảnh.

Hàm băm thân thiện với STARK và khả năng chống lượng tử

STARK thường được thảo luận là chủ yếu dựa vào hàm băm và các kỹ thuật lý thuyết thông tin, thay vì pairing đường cong elliptic.

Điều này tạo cho hệ thống STARK hồ sơ bảo mật khác với một số hệ thống chứng minh dựa vào đường cong thân thiện với pairing.

Tuy nhiên, người dùng nên cẩn trọng với các tuyên bố quá rộng về khả năng chống lượng tử.

Hàm băm thân thiện với STARK vẫn phụ thuộc vào bảo mật của hàm băm và các tham số bảo mật đã chọn.

Thuật toán lượng tử có thể ảnh hưởng mức bảo mật bằng cách thay đổi chi phí hiệu dụng của một số cuộc tấn công.

Nhà phát triển có thể cần đầu ra lớn hơn hoặc tham số mạnh hơn để duy trì biên độ bảo mật mong muốn.

Cụm từ thân thiện với STARK không tự động có nghĩa an toàn trước mọi mối đe dọa mật mã trong tương lai.

Nó có nghĩa hàm băm hoạt động hiệu quả trong hệ thống chứng minh kiểu STARK.

Bảo mật trước kẻ tấn công cổ điển và lượng tử vẫn phải được đánh giá riêng.

Kỹ thuật mật mã tốt tránh biến thuật ngữ marketing thành bảo đảm bảo mật.

Lợi ích của hàm băm thân thiện với STARK

Lợi ích đầu tiên của hàm băm thân thiện với STARK là chi phí chứng minh thấp hơn.

Ít ràng buộc đại số hơn có thể giảm khối lượng công việc của prover.

Lợi ích thứ hai là tạo chứng minh nhanh hơn cho các ứng dụng cần nhiều thao tác băm.

Điều này có thể cải thiện trải nghiệm người dùng trong rollup, công cụ riêng tư và ứng dụng có thể xác minh.

Lợi ích thứ ba là xác minh chứng minh Merkle rẻ hơn trong STARK.

Điều này quan trọng với cây trạng thái, cây nullifier, allowlist và cây cam kết.

Lợi ích thứ tư là tương thích tốt hơn với số học trường hữu hạn.

Các thao tác gốc trường dễ số học hóa hơn nhiều thao tác bit.

Lợi ích thứ năm là khả năng mở rộng cho xử lý batch.

Khi nhiều hash được chứng minh cùng lúc, mức tăng hiệu quả có thể cộng dồn đáng kể.

Rủi ro và hạn chế của hàm băm thân thiện với STARK

Rủi ro đầu tiên là mức độ trưởng thành có thể thấp hơn so với các hàm băm truyền thống lâu đời.

Một số hàm băm thân thiện với STARK có ít phân tích thực tế kéo dài nhiều thập kỷ hơn SHA-256 hoặc Keccak.

Rủi ro thứ hai là sử dụng sai tham số.

Thay đổi số vòng, hằng số, lựa chọn trường hoặc mã hóa có thể làm suy yếu bảo mật.

Rủi ro thứ ba là lỗi tương thích.

Giao thức yêu cầu Keccak hoặc SHA-256 không thể chỉ chấp nhận Poseidon nếu không thay đổi quy tắc xác minh.

Rủi ro thứ tư là lỗi triển khai.

Các lỗi số học trường, tuần tự hóa, thứ tự byte và giảm mô-đun có thể làm hỏng tính chính xác.

Rủi ro thứ năm là lỗi phân tách miền.

Dùng cùng đầu vào hash ở các ngữ cảnh khác nhau mà không có nhãn có thể tạo ra sự mơ hồ nguy hiểm.

Rủi ro thứ sáu là khái quát hóa quá mức.

Hàm băm hiệu quả trong một hệ thống chứng minh có thể không lý tưởng trong hệ thống khác.

Nhà phát triển nên xem hàm băm thân thiện với STARK là công cụ mật mã chuyên biệt, không phải sản phẩm thay thế cắm là chạy cho mọi hàm băm.

Những hiểu lầm phổ biến về hàm băm thân thiện với STARK

Một hiểu lầm phổ biến là hàm băm thân thiện với STARK tự động an toàn hơn SHA-256 hoặc Keccak.

Thân thiện với STARK nghĩa là hiệu quả cho hệ thống chứng minh STARK, không phải mạnh hơn một cách phổ quát.

Một hiểu lầm khác là hàm băm truyền thống đã lỗi thời.

Hàm băm truyền thống vẫn thiết yếu cho nhiều giao thức blockchain, chữ ký, địa chỉ và lớp tương thích.

Hiểu lầm thứ ba là Poseidon, Pedersen và Rescue có thể thay thế lẫn nhau.

Chúng có thiết kế, tham số, hồ sơ hiệu năng và vai trò hệ sinh thái khác nhau.

Hiểu lầm thứ tư là chỉ một hàm băm đã khiến hệ thống trở nên riêng tư.

Quyền riêng tư cần toàn bộ thiết kế giao thức, gồm cam kết, nullifier, chứng minh, ví và cách xử lý dữ liệu.

Hiểu lầm thứ năm là nhà phát triển có thể tự do thay đổi tham số hash để tăng tốc.

Tham số mật mã chỉ nên được thay đổi khi có phân tích chuyên môn và đánh giá chặt chẽ.

Cách đánh giá hàm băm thân thiện với STARK

Hãy bắt đầu bằng việc kiểm tra liệu hàm băm có được thiết kế cho đúng hệ thống chứng minh bạn sử dụng hay không.

Đánh giá liệu hàm băm có hoạt động trên cùng trường hữu hạn với hệ thống STARK của bạn hay không.

Kiểm tra liệu hàm băm có phân tích mật mã được công bố hay không.

Kiểm tra tham số có được chuẩn hóa, ghi chép và đánh giá rộng rãi hay không.

Đánh giá chi phí prover, mức sử dụng bộ nhớ và ràng buộc chứng minh trên khối lượng công việc thực tế.

Kiểm tra xem có thư viện đáng tin cậy trong môi trường lập trình của bạn hay không.

Đánh giá liệu hàm băm đã được chain, ví, ngôn ngữ hợp đồng hoặc prover stack của bạn hỗ trợ hay chưa.

Kiểm tra liệu hàm băm có cần tương thích với dữ liệu Keccak, SHA-256 hoặc Pedersen hiện có không.

Đánh giá cẩn thận các quy tắc phân tách miền và mã hóa đầu vào.

Không chọn hàm băm chỉ vì nó có benchmark thấp hơn trong một bài kiểm tra riêng lẻ.

Thực hành tốt nhất cho nhà phát triển

Sử dụng hàm băm giao thức chính thức khi tính hash giao dịch, khóa lưu trữ, chữ ký hoặc địa chỉ.

Dùng các hàm băm thân thiện với STARK được khuyến nghị cho cam kết nội bộ gốc cho chứng minh khi khả năng tương thích cho phép.

Tuân theo tài liệu chính thức của Cairo, Starknet hoặc framework STARK mục tiêu.

Không thiết kế tham số hash tùy chỉnh trừ khi bạn có chuyên môn mật mã và đánh giá độc lập.

Dùng phân tách miền rõ ràng cho các ngữ cảnh hash khác nhau.

Dùng tuần tự hóa không mơ hồ cho phần tử trường, mảng byte, danh sách và cặp giá trị.

Kiểm tra đầu ra hash dựa trên test vector đã biết.

Audit mã chuyển đổi giữa byte và phần tử trường.

Benchmark chi phí prover trên khối lượng công việc thực tế thay vì chỉ đo tốc độ hash phần mềm.

Ghi chép lý do sử dụng từng hàm băm và các giả định tương thích mà nó phụ thuộc.

Thực hành tốt nhất cho người dùng

Hiểu rằng hàm băm thân thiện với STARK chủ yếu là công cụ hạ tầng được ví, rollup, hợp đồng và hệ thống chứng minh sử dụng.

Đừng cho rằng dự án an toàn chỉ vì dùng Poseidon, Pedersen, Rescue hoặc hàm băm thân thiện với ZK khác.

Kiểm tra xem ứng dụng có audit, tài liệu chính thức và giả định bảo mật rõ ràng hay không.

Cẩn trọng với bridge vì khả năng tương thích hash giữa các chain có thể phức tạp.

Sử dụng phần mềm ví đáng tin cậy tuân theo quy tắc hash chính thức của mạng mục tiêu.

Không tự tạo lại hash giao dịch nếu chưa hiểu thông số kỹ thuật giao thức.

Hãy nhớ hiệu quả hash không loại bỏ rủi ro hợp đồng thông minh, rủi ro khóa riêng tư, rủi ro oracle hoặc rủi ro bridge.

Hiểu rằng ứng dụng riêng tư cần nhiều hơn hàm băm để bảo vệ dữ liệu người dùng.

Theo dõi các nâng cấp giao thức có thể thay đổi hàm băm được khuyến nghị hoặc định dạng giao dịch.

Chỉ xem lựa chọn hàm băm là dấu hiệu về chất lượng kỹ thuật khi nó đi kèm triển khai và đánh giá chặt chẽ.

FAQ

Hàm băm thân thiện với STARK nghĩa là gì?

Hàm băm thân thiện với STARK là hàm băm được thiết kế để hoạt động hiệu quả trong hệ thống chứng minh STARK bằng cách sử dụng các thao tác dễ biểu diễn thành ràng buộc đại số.

Vì sao hàm băm thân thiện với STARK được dùng trong crypto?

Chúng được dùng vì rollup, hệ thống riêng tư, cây Merkle và cam kết thường cần nhiều hash; hàm băm hiệu quả có thể giảm chi phí chứng minh.

Poseidon có phải hàm băm thân thiện với STARK không?

Có. Poseidon là hàm băm thân thiện với ZK được dùng rộng rãi, hiệu quả trong nhiều hệ thống chứng minh trường hữu hạn và được khuyến nghị cho nhiều chương trình Cairo.

Pedersen có phải hàm băm thân thiện với STARK không?

Pedersen đã được dùng trong Starknet và các hệ thống mật mã khác, nhưng Poseidon thường được ưu tiên hơn cho khối lượng công việc chứng minh STARK mới vì có thể rẻ hơn và nhanh hơn trong các bối cảnh liên quan.

SHA-256 có thân thiện với STARK không?

SHA-256 an toàn và được sử dụng rộng rãi, nhưng thường không được xem là thân thiện với STARK vì các thao tác bit của nó có thể tốn kém để chứng minh trong nhiều hệ thống chứng minh đại số.

Keccak có thân thiện với STARK không?

Keccak được sử dụng rộng rãi trong blockchain, nhưng thiết kế cấp bit của nó có thể tốn kém trong các hệ thống chứng minh dựa trên trường so với các hàm băm được thiết kế cho số học hóa đại số.

Thân thiện với STARK có nghĩa là an toàn hơn không?

Không. Thân thiện với STARK nghĩa là hiệu quả cho việc chứng minh STARK; bảo mật phụ thuộc vào thiết kế mật mã, tham số, triển khai và quá trình đánh giá.

Hàm băm thân thiện với STARK được dùng ở đâu?

Chúng được dùng trong cây Merkle, cam kết, nullifier, băm giao dịch, khóa lưu trữ, cập nhật trạng thái rollup, hệ thống riêng tư và logic ứng dụng gốc cho chứng minh.

Nhà phát triển có thể thay mọi hàm băm bằng Poseidon không?

Không. Nhà phát triển phải dùng hàm băm được yêu cầu trong từng bối cảnh giao thức vì địa chỉ, bố cục lưu trữ, chữ ký và chứng minh bridge có thể phụ thuộc vào các hàm băm cụ thể.

Rủi ro chính khi dùng hàm băm thân thiện với STARK là gì?

Các rủi ro chính là dùng sai tham số, lỗi triển khai, phân tách miền yếu và dùng hàm băm trong bối cảnh cần một hàm khác để tương thích.

Kết luận

Hàm băm thân thiện với STARK là hàm băm được tối ưu để chứng minh hiệu quả trong các hệ thống không kiến thức dựa trên STARK.

Nó được thiết kế để hoạt động tốt với trường hữu hạn, ràng buộc đại số và tính toán gốc cho chứng minh.

Điều này khiến nó khác với các hàm băm truyền thống như SHA-256 và Keccak, vốn là những hàm băm đa dụng xuất sắc nhưng có thể tốn kém để chứng minh trong nhiều môi trường ZK.

Hàm băm thân thiện với STARK quan trọng vì rollup, giao thức riêng tư, cây Merkle, cam kết, nullifier, khóa lưu trữ và hash giao dịch có thể cần lượng thao tác băm rất lớn.

Poseidon là một trong các ví dụ nổi tiếng nhất, và tài liệu Cairo chính thức khuyến nghị dùng nó cho nhiều chương trình Cairo vì nó rẻ hơn và nhanh hơn Pedersen trong bối cảnh chứng minh STARK.

Pedersen vẫn quan trọng trong các bối cảnh Starknet legacy và hệ thống mật mã khác.

Rescue và các hàm băm định hướng số học hóa khác cho thấy lĩnh vực này tiếp tục phát triển.

Lợi ích chính của hàm băm thân thiện với STARK là chi phí chứng minh thấp hơn cho khối lượng công việc cần nhiều hash.

Rủi ro chính là cho rằng hiệu quả chứng minh tự động đồng nghĩa bảo mật hoặc khả năng tương thích phổ quát.

Nhà phát triển phải tuân theo thông số kỹ thuật chính thức, dùng tham số đã được đánh giá, áp dụng phân tách miền, kiểm tra kỹ tuần tự hóa và chọn đúng hàm băm cho từng bối cảnh giao thức.

Người dùng không cần trực tiếp quản lý các hàm băm này, nhưng được hưởng lợi khi rollup, ví và ứng dụng riêng tư sử dụng chúng đúng cách.

Trong ngữ cảnh thuật ngữ crypto, STARK-Friendly Hash là hàm băm hiệu quả cho chứng minh, được thiết kế cho hệ thống STARK, trong đó hiệu năng đại số, bảo mật mật mã và khả năng tương thích giao thức đều cần được cân bằng.

Điểm chính cần nhớ là hàm băm thân thiện với STARK giúp các hệ thống blockchain không kiến thức nhanh hơn và rẻ hơn, nhưng phải được triển khai với kỷ luật mật mã cẩn trọng và quy tắc giao thức chính xác.