Một bản tóm tắt về tất cả mọi thứ liên quan đến crescendo, những gì được bao gồm, lợi ích là gì, v.v. Điều này có thể chứa nhiều chi tiết, vì vậy hãy giữ chặt. Tăng số lượng khối mỗi giây từ 1 đến 10 bps trong khi giữ dung lượng khối ~cố định (sẽ nói thêm về điều đó sau). Lưu lượng: rõ ràng, lưu lượng giao dịch tăng lên. Bao nhiêu? gần gấp mười lần nhưng không chính xác là 10x. Có nhiều khối song song hơn làm tăng tỷ lệ va chạm đến một mức độ nào đó. Trên TN10 và với chính sách lựa chọn giao dịch mempool hiện tại, chúng tôi quan sát thấy hiệu quả ~80-90% (tức là, 80-90% các giao dịch là duy nhất). Nếu mempool bị quá tải và nhu cầu vượt quá dung lượng đáng kể, giá trị hiệu quả này sẽ tiến tới 100%. Vì vậy, để kết luận, TPS đang tăng 8-9x. Thông tin thiếu là chiều rộng DAG trung bình của mainnet sau khi kích hoạt so với hôm nay. Các chính sách mempool có thể được tinh chỉnh trong tương lai mà không cần hardfork dựa trên dữ liệu thực tế như vậy. Tần suất: thời gian khối trung bình (=khoảng cách giữa các khối) đang được giảm từ 1 giây xuống 100 mili giây. Điều này có nghĩa là thời gian bao gồm giao dịch nhanh như chớp mắt. Một giao dịch không cần phải lan truyền đến toàn bộ mạng để được bao gồm; ví dụ, nó có thể đến được các thợ đào trong lục địa của nó trong 50ms và được khai thác sau 200ms. Tần suất cũng giảm thời gian xác nhận sau khi bao gồm do mật độ tăng của quá trình lấy mẫu khai thác. Không phải nói rằng thời gian xác nhận giảm gấp mười lần, vì chúng hiện bị chi phối bởi độ trễ khối chưa thay đổi. Thay vào đó, bằng các tính toán sơ bộ, chúng đã cải thiện 30% (đối với người tiên tiến: đuôi của Poisson điều khiển chiều rộng DAG trường hợp xấu nhất giảm nhanh hơn, do đó K có thể được đặt tương đối thấp hơn, từ 18 (1bps) đến 124 (cho 10bps) và không phải là 180 như người ta có thể mong đợi). Song song khối: song song khối tăng với tốc độ khối, và điều đó, trái ngược với những gì bạn có thể nghĩ, là tốt. Mặc dù va chạm tăng nhẹ do song song khối, song song là rất quan trọng để tạo ra một hệ thống công bằng hơn. Nó có nghĩa là không có sự độc quyền của một thợ đào chiến thắng duy nhất mỗi vòng, mà thay vào đó các khối phải cạnh tranh và đưa ra quyết định khôn ngoan và cạnh tranh trong vòng độ trễ. Các tác động có thể rất lớn và sâu rộng. Các hệ thống Oracle và đấu giá kickback MEV là một số nỗ lực sơ bộ. Đi sâu hơn vào điều này là ngoài phạm vi. Tôi cũng cần giải thích tại sao tài chính trở nên quan trọng hơn sau crescendo... giả sử đó là trường hợp, tôi nghĩ rằng ngay cả khi không thực hiện các thiết kế kickback MEV rõ ràng trong sự đồng thuận (chưa), sự hỗn loạn nội vòng của DAG song song ở 10 bps sẽ làm cho việc thao túng kinh tế khó khăn hơn nhiều so với các hệ thống dựa trên lãnh đạo khác. Các thay đổi khác được bao gồm trong crescendo. Làm thế nào để tôi bắt đầu, có rất nhiều. KIP-9 được tích hợp vào sự đồng thuận, tích hợp giải pháp bloat trạng thái độc đáo của chúng tôi vào hệ thống. Nhân tiện, chúng tôi gọi giao thức con “harmonic” này là tên STORM (cho STORage Mass). Trong quá trình này, KIP-9 đã được mở rộng để bao gồm sự đa dạng lưu trữ UTXO (tức là, đánh thuế một UTXO tiêu thụ nhiều lưu trữ hơn một cách thích hợp), làm cho nó trở nên tương lai hơn. KIP-10 thêm hỗ trợ cho các giao ước cơ bản và địa chỉ bổ sung. KIP-13 điều chỉnh yêu cầu lưu trữ tạm thời nghiêm ngặt hơn. Các thay đổi liên quan đến hợp đồng thông minh: KIP-14 cho phép tải trọng, cho phép các giao dịch mang dữ liệu tùy ý (ví dụ, các cuộc gọi chức năng hợp đồng thông minh). KIP-15 là một nâng cấp kỹ thuật nhỏ - bao gồm một dòng mã - nhưng cho phép một tính năng có ý nghĩa về mặt khái niệm, cho phép các nút chỉ lưu trữ các giao dịch và chứng minh sự sắp xếp và chấp nhận của chúng một cách không tin cậy. Điều này có ý nghĩa quan trọng để cho phép các nút L2 thời kỳ trước zk lưu trữ và chứng minh việc thực hiện SC đầy đủ cho các bộ đồng bộ mới với chi phí hợp lý - do đó thực sự làm cho các hệ thống như vậy có thể ngay sau crescendo. Thay đổi được đề xuất là một tập hợp nhỏ của đề xuất thiết kế zk (xem các bài đăng thiết kế rollups trên diễn đàn nghiên cứu Kaspa) nơi một cơ chế như vậy được đề xuất như một yêu cầu cần thiết để các hệ thống zk hoạt động trên Kaspa, và hóa ra có giá trị đáng kể cũng trước zk. Nhìn chung, điều này có nghĩa là các L2 SC sơ bộ có thể có trên Kaspa sau crescendo (hoặc Kaspa 2.0 như @hashdag gọi nội bộ) với các mô hình tin cậy đủ. Những điều khác tôi muốn viết về nhưng sẽ chờ đợi một thời gian khác: khảo sát chi phí phần cứng tăng nhưng hạn chế của nâng cấp này, tại sao tôi suy đoán chiều rộng DAG của mainnet sẽ không tăng gấp mười lần sau crescendo (gợi ý: tuyên bố lục địa ở trên; tức là, địa phương trong mạng P2P), và nhiều hơn nữa. Vui lòng hỏi về bất cứ điều gì không rõ ràng hoặc cần giải thích.