ERPC công bố báo cáo "How to be faster on Solana?" (Làm thế nào để nhanh hơn trên Solana?) — Trực quan hóa điều gì quyết định tốc độ trên Solana như một bài toán vật lý về khoảng cách mạng, kèm dữ liệu trực tiếp
ERPC công bố báo cáo "How to be faster on Solana?" (Làm thế nào để nhanh hơn trên Solana?) — Trực quan hóa điều gì quyết định tốc độ trên Solana như một bài toán vật lý về khoảng cách mạng, kèm dữ liệu trực tiếp
ELSOUL LABO B.V. (Trụ sở chính: Amsterdam, Hà Lan; CEO: Fumitake Kawasaki) và Validators DAO, hai đơn vị vận hành ERPC, hân hạnh thông báo về việc công bố "How to be faster on Solana?" (Làm thế nào để nhanh hơn trên Solana?), một trang báo cáo trình bày — trong một mạch đọc liền, từ trên xuống dưới, mà ngay cả lập trình viên không chuyên cũng nắm bắt được trong nháy mắt — cách để trở nên nhanh hơn trên Solana.
Trong những năm gần đây, ngày càng nhiều lập trình viên và đội ngũ đã dấn thân vào giao dịch tần suất cao (HFT) và hạ tầng tài chính thời gian thực trên blockchain, và đặc biệt là trên Solana. Thế nhưng kiến thức đằng sau những câu hỏi cơ bản nhất — vì sao có người nhanh hơn, và làm thế nào để nhanh hơn — vẫn nằm rải rác trong từng bài blog kỹ thuật riêng lẻ và những lời giải thích vụn vặt, với rất ít tài liệu cho phép nắm bắt toàn cảnh một cách nhanh chóng. Báo cáo này tổ chức lại cốt lõi của các bài viết kỹ thuật mà ERPC đã công bố theo thời gian thành một "đường vật lý" liền mạch.
Báo cáo này chia sẻ những hiểu biết thực tiễn để sử dụng mạng hiệu quả hơn và với tốc độ cao hơn — ngay cả trên một mạng phi tập trung mà những người tham gia trải khắp thế giới. Chúng tôi tin rằng việc chia sẻ một cách có hệ thống về nơi nào, và vì sao, lại phát sinh khác biệt về tốc độ sẽ đóng góp cho hiệu quả và sự phát triển lành mạnh của hệ sinh thái blockchain rộng lớn hơn, bao gồm cả Solana, vượt ra ngoài lợi ích của bất kỳ một nhà cung cấp riêng lẻ nào.
How to be faster on Solana? (báo cáo): https://erpc.global/vi/how-to-be-faster/
Trang chính thức của ERPC: https://erpc.global/vi
Bảng điều khiển ERPC: https://dashboard.erpc.global/vi
Điều quyết định tốc độ không phải mã của bạn hay máy của bạn — Mà là lớp thứ ba vô hình
"Tôi chạy cùng một chiến lược, vậy mà chỉ riêng bot của tôi bị khớp lệnh muộn." "Giá cập nhật bình thường, nhưng chỉ riêng giao dịch của tôi không vào được." "Tôi đã đổi nhà cung cấp RPC, mà chẳng có gì thay đổi." — những lời than phiền của các lập trình viên đang cạnh tranh về tốc độ trên Solana giống nhau đến lạ thường.
Nghi can đầu tiên luôn là "chắc mã của mình chậm" hoặc "chắc cấu hình của mình chưa đủ tốt." Tối ưu mã và máy của bạn dĩ nhiên có ích. Nhưng trong nhiều trường hợp bạn đã tinh chỉnh cả hai một cách kỹ lưỡng, thứ còn lại cho đến tận cùng — và bị bỏ qua nhiều nhất — là một lớp thứ ba vô hình: khoảng cách mạng của bạn đến Solana.
Một khi đường thực thi của bạn đã được tối ưu tốt, những gì việc tinh chỉnh CPU ở cấp lệnh còn cắt bớt được nằm trong thế giới của nano-giây đến nhiều nhất là vài micro-giây. Khoảng cách mạng, ngược lại, chi phối hàng trăm mili-giây — một đòn bẩy ở mức độ khoảng 1000x đang ngủ yên trong lớp mà người ta bỏ qua nhiều nhất. Vượt qua điểm bạn đã đánh bóng mã và máy của mình, dư địa lớn nhất còn lại nằm ở lớp thứ ba đó.
Trên Solana, "nơi nhanh nhất" di chuyển khắp thế giới theo mỗi slot
Trên Solana, một slot tiến lên khoảng mỗi 400 mili-giây, và mỗi slot có một validator được chỉ định làm "leader" để dựng phần block đó. Các leader luân chuyển nhanh chóng (cùng một validator có thể giữ vài slot liên tiếp), và máy chủ gần leader đó nhất giành được lợi thế lớn cho slot đó.
Đây chính là điều khiến nó khác biệt về căn bản so với giao dịch tần suất cao truyền thống. Trong cổ phiếu hay ngoại hối, việc đặt máy chủ của bạn ngay cạnh cỗ máy khớp lệnh duy nhất của sàn — một điểm cố định không di chuyển — giữ cho bạn dẫn trước mãi mãi. Trên Solana, leader di chuyển khắp thế giới theo từng slot. Chỗ ngồi nhanh nhất mỗi lần lại ở một nơi khác. Cắm trại cạnh một điểm một lần rồi xong chuyện đơn giản là không hiệu quả ở đây.
Trong báo cáo, một quả địa cầu được vận hành bởi dữ liệu trực tiếp từ Leader Slot Information API (getLeaderSlots) của ERPC hiển thị leader hiện tại, và sự luân chuyển chóng mặt của nó, đúng như nó đang diễn ra. "Nơi nhanh nhất cứ di chuyển" — đây không phải một phép ẩn dụ, mà là một sự thật bạn có thể quan sát trực tiếp.
Khoảng cách là độ trễ — Từ ~0.1ms trên cùng một mạng đến 100–300ms qua các châu lục
Tốc độ ánh sáng qua sợi quang, và số lần nhảy qua router (hops) dọc theo đường đi, đặt ra một mức sàn mà không phần cứng nào có thể vượt qua. Khoảng cách phát huy tác dụng đại khái theo các bậc độ lớn sau:
- Cùng một mạng: ~0.1ms
- Cùng một trung tâm dữ liệu: ~0.3ms
- Cùng một thành phố: ~1ms
- Quốc gia lân cận: ~5–10ms
- Qua các châu lục: ~100–300ms
Một slot chỉ vào khoảng 400 mili-giây. 100–300 mili-giây để vượt qua một châu lục đã ngốn hết cửa sổ của trọn một slot ngay tự thân nó. Khi leader ở ngay trước cửa nhà bạn, bạn lọt vào trong cửa sổ; khi nó ở phía bên kia hành tinh, bạn đã lỡ mất trước cả khi gửi đi. Nhanh ở mọi slot nghĩa là luôn "ở gần" bất cứ nơi nào leader đáp xuống.
Lưu ý rằng những sự tương phản trong báo cáo — "~0.1ms trên cùng một mạng" so với "trên một đường đi vòng vèo, số lần nhảy chuyển tiếp (hops = các router mà tín hiệu đi qua) tăng lên khoảng 7, và độ trễ giãn rộng ra khoảng 70x" — là các con số tròn nhằm truyền đạt, một cách trực giác, khoảng cách giữa một tuyến gần và một tuyến xa. Những biến động lớn được đo lường xuất hiện trong dữ liệu trực tiếp từ Leader Slot Information API của ERPC: độ trễ đo được từ một node nhất định đến leader thay đổi rất nhiều tùy thuộc vào nơi leader ở đâu (slot nào), và những biến động ở mức độ vài chục lần giữa các slot gần và xa đã được quan sát thấy. Một con số "độ trễ trung bình" duy nhất thường chỉ là một slot nhanh và một slot chậm thay phiên nhau; giá trị trung bình thường che giấu thực tế.
Và một "tên thành phố" không phải là bản thân đường đi của mạng. Ngay cả trong cùng một thành phố, nếu chen vào các chặng transit bên ngoài hoặc các bước nhảy phụ, độ trễ chồng chất thêm đúng bằng chừng đó. Đó chính xác là lý do bạn chọn node gần nhất theo thời gian đến đo được (ping), chứ không phải theo khoảng cách trên bản đồ.
Một thành phố là không đủ — Đa vùng, luôn ở gần leader
Thành phố nơi các validator của Solana tụ tập dày đặc nhất là Frankfurt. Dù vậy, trong một ảnh chụp nhanh được đo tại thời điểm công bố, các validator tập trung ở Frankfurt chỉ chiếm khoảng một phần tư của toàn bộ mạng — xét cả theo số lượng validator lẫn theo stake. Khoảng ba phần tư số slot còn lại được dẫn dắt từ một nơi nào đó khác ngoài Frankfurt.
Nói cách khác, ngay cả khi bạn đặt cỗ máy tốt nhất của mình ở thành phố đông đúc nhất, riêng điều đó cũng không bao giờ có thể khiến bạn "luôn nhanh nhất." Túc trực ở nhiều vùng (ví dụ Frankfurt / Amsterdam / New York / Tokyo / Singapore), nhận tín hiệu ở gần bất cứ leader nào đang hoạt động, và chuyển giao khi leader di chuyển — đây là cách để nhanh ở mọi slot.
Khi giao dịch của bạn không vào được, bạn đang kẹt trong làn spam
Tốc độ không chỉ là vấn đề máy chủ của bạn đặt ở đâu. Làn mà bạn chuyển giao dịch của mình qua cũng quyết định thành công hay thất bại.
Trong dung lượng của TPU (Transaction Processing Unit) tiếp nhận giao dịch, leader phân bổ tới khoảng 80% cho ưu tiên theo trọng số stake — tức là cho các kết nối được hậu thuẫn bởi SOL đã cam kết vào một validator (stake) (SWQoS / Stake-Weighted Quality of Service). Khoảng 20% còn lại được chia sẻ bởi mọi kết nối khác. Phần sau là một làn đông nghẹt nhồi nhét spam. Lưu ý rằng mức phân bổ ~80% này được quyết định ở phía leader như một vấn đề thuộc giao thức của Solana, không phải thứ ERPC ấn định.
Bắn thẳng giao dịch vào leader có cảm giác như là nước đi nhanh nhất. Nhưng nếu không có sự hậu thuẫn của stake, điều đó có nghĩa là xếp hàng trong làn ~20% đông nghẹt, và dưới tải, giao dịch của bạn rốt cuộc không bao giờ vào được block. Câu trả lời cốt yếu là gửi qua một đường được hậu thuẫn bởi stake — từ một RPC được kết nối với một staked validator thông qua mối quan hệ trusted-peer. ERPC vận hành một staked validator hàng đầu, được kết nối với các đường RPC chất lượng cao, làm hậu thuẫn cho điều này (Shinobi Performance Pool).
Phần cứng chỉ quan trọng khi nó chạy hết công suất
Ngay cả một máy chủ đặt đúng chỗ cũng không thể tận dụng sự gần gũi mà nó giành được nếu bản thân cỗ máy không chạy hết tốc lực. Một VPS ảo hóa chia sẻ một hypervisor, nên nó dễ bị jitter và đình trệ từ "hàng xóm ồn ào" đúng vào lúc mọi thứ đông đúc nhất. Bare metal chuyên dụng không gặp điều đó. Mức sàn xung nhịp mà một Solana validator phải đáp ứng là 2.8GHz; bare metal của ERPC chạy cao hơn hẳn mức đó, ở một xung nhịp cao thuộc hạng 5.7GHz, trong khi giữ mức sử dụng ở 30–40% — bởi một CPU bị ghim ở 95% sinh ra jitter như một con đường tắc nghẽn.
Khác biệt này không chỉ giới hạn ở bare metal hàng đầu. Trong báo cáo, chúng tôi đặt VPS của ERPC (VPS++) cạnh một máy ảo của một đám mây lớn có cấu hình tương đương (cả hai đều AMD Turin / 4 vCPU) bằng một bài benchmark thực tế (node_bench). Đây không phải một màn dàn dựng; đây là một "phép đo" mà bất kỳ ai cũng có thể tái lập bằng cùng phương pháp. ERPC luôn nhất quán nhấn mạnh việc chứng minh chất lượng và tốc độ cung cấp thông qua đo lường, chứ không phải qua những tuyên bố chủ quan hay ngôn từ tiếp thị.
Câu trả lời cuối cùng: Cùng một mạng = Khoảng cách bằng không
Nơi mà toàn bộ mạch lập luận này dẫn đến là một điểm duy nhất: việc ở "cùng một mạng" với hạ tầng của Solana — RPC, các validator, và các đường thời gian thực liên quan đến giao dịch, chẳng hạn như Jito và Shredstream. Trên cùng một mạng thì là ~0.1ms, và các gói tin không bao giờ băng qua internet công cộng. "Qua internet công cộng," mặc định đối với hầu hết mọi người, chính xác là lý do hầu hết mọi người chậm. Khoảng cách bằng không là kết luận buộc chặt vị trí, máy móc, và stake lại với nhau.
ERPC — Mọi tối ưu mà vật lý đòi hỏi, trên một nền tảng duy nhất
Với mỗi câu trả lời mà báo cáo rút ra như vật lý, ERPC đều có sẵn một phương tiện tương ứng: VPS và bare metal trên cùng một mạng (khoảng cách bằng không), túc trực ở nhiều vùng (FRA / AMS / NY / TYO / SGP) (luôn nhanh nhất), định tuyến dựa trên ping đo được (đến node thực sự gần nhất theo đường đi, chứ không theo bản đồ), getLeaderSlots API (biết vị trí của leader theo từng slot), và bare metal hạng 5.7GHz được tinh chỉnh bằng SLV mã nguồn mở (hết công suất).
ERPC ra đời bởi vì ngay từ đầu chính chúng tôi cần đến nó. Khi vận hành Epics DAO mã nguồn mở (một trò chơi thẻ bài trên Solana), chúng tôi không thể mua được loại hạ tầng này ngay cả khi đã cố gắng, nên chúng tôi không còn lựa chọn nào khác ngoài tự xây dựng nó. Giờ đây bạn có thể đứng trên chính nền tảng đó.
Trên ERPC, bạn có thể kết hợp Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, máy chủ bare-metal, RPC chuyên dụng, SWQoS, một Price API hỗ trợ Pyth, cùng Jet Analytics & Indexed RPC trên một nền tảng duy nhất.
Sử dụng các mạng phi tập trung nhanh hơn và hiệu quả hơn
Có một phần của tốc độ có thể được cải thiện thông qua đầu tư hạ tầng đúng đắn. Nhưng điều mà báo cáo này nhất quán cố gắng truyền đạt là việc hiểu được "nơi nào, và vì sao, khác biệt phát sinh" mới là lợi thế thực sự. Một khi bạn hiểu nơi mình đang đánh mất thời gian — vị trí, đường đi, máy móc, hay stake — bạn khi đó có thể chọn đúng nguồn lực và tập trung vào công việc cốt lõi của mình: chiến lược, lập trình, và phát triển.
Ngay cả trên một mạng phi tập trung, mạng vẫn có thể được sử dụng một cách hiệu quả. Việc chia sẻ thực tế đó theo một cách có hệ thống sẽ đóng góp cho hiệu quả và sự phát triển của hệ sinh thái blockchain rộng lớn hơn, bao gồm cả Solana, vượt ra ngoài lợi ích của bất kỳ một nhà cung cấp riêng lẻ nào.
R&D và cải tiến liên tục hạ tầng chuyên biệt cho Solana
Đằng sau ERPC là hoạt động nghiên cứu và phát triển hạ tầng chuyên biệt cho Solana mà ELSOUL LABO không ngừng theo đuổi. ELSOUL LABO đã được phê duyệt năm năm liên tiếp kể từ 2022 theo WBSO, chương trình hỗ trợ R&D của chính phủ Hà Lan. Đơn vị tiếp tục R&D về hạ tầng Solana RPC, vận hành validator, cung cấp dữ liệu thời gian thực, và vận hành cùng phát triển có sự hỗ trợ của AI-agent, và những kết quả đó được phản ánh trên các dịch vụ bao gồm ERPC, SLV, SLV AI, và trung tâm dữ liệu AS200261 chuyên biệt cho Solana. Việc công bố báo cáo này, cũng vậy, là một nỗ lực nối tiếp trực tiếp từ hoạt động nghiên cứu và phát triển liên tục này. ERPC sẽ tiếp tục công bố các kết quả của mình theo một cách có hệ thống.
Sử dụng và tư vấn
Đối với các câu hỏi về nội dung của báo cáo này, tư vấn về cải thiện tốc độ cho hệ thống của riêng bạn, trợ giúp chọn nguồn lực hoặc lập kế hoạch di chuyển, hay các câu hỏi về benchmark, vui lòng tạo một ticket hỗ trợ trên Discord chính thức của Validators DAO.
How to be faster on Solana? (báo cáo): https://erpc.global/vi/how-to-be-faster/
Bảng điều khiển ERPC: https://dashboard.erpc.global/vi
Trang chính thức của ERPC: https://erpc.global/vi
Discord chính thức của Validators DAO: https://discord.gg/C7ZQSrCkYR
Chúng tôi chân thành cảm ơn tất cả người dùng vì đã tiếp tục sử dụng ERPC.
Liên kết
- How to be faster on Solana? (báo cáo): https://erpc.global/vi/how-to-be-faster/
- Trang chính thức của ERPC: https://erpc.global/vi
- Bảng điều khiển ERPC: https://dashboard.erpc.global/vi
- Bảng giá ERPC: https://erpc.global/vi/price/
- Trang chính thức của SLV: https://slv.dev/vi
- SLV GitHub: https://github.com/validatorsDAO/slv
- Discord chính thức của Validators DAO: https://discord.gg/C7ZQSrCkYR
Tin tức
