NurseeGabriel

Hầu hết các dự án Blockchain chỉ đơn giản là nói "chúng tôi đã xử lý hàng triệu giao dịch"
Đúng vậy... đó là một thành tựu quan trọng, nhưng vấn đề là LÀM SAO NGƯỜI DÙNG BIẾT liệu những tuyên bố đó có đúng hay không? Đây chính là bài toán!
Câu hỏi đòi hỏi một câu trả lời và câu trả lời chính là giải pháp. Đây là nơi RAYLS phát huy tác dụng.
Bây giờ... hãy cùng phân tích nhé.
RAYLS với cách tiếp cận đột phá đã đưa ra mô hình Tính minh bạch và khung chứng minh việc sử dụng. Nhưng trước hết, hãy hiểu khái niệm về chứng minh việc sử dụng mà Rayls mang đến.

Việc ứng dụng Blockchain của các ngân hàng và các tổ chức tài chính khác lại dẫn đến một đợt tái cơ cấu khác
Dưới đây là lý do vì sao
Những thách thức của việc áp dụng Blockchain hiện nay đối với các ngân hàng và các tổ chức tài chính được quản lý khác là QUYỀN RIÊNG TƯ.
Trong khi Blockchain vẫn giữ phong cách minh bạch và bất biến truyền thống của mình... thì các ngân hàng và các tổ chức tài chính khác nói trên lại phải đối mặt với những thách thức trong việc bảo vệ thông tin khách hàng, dữ liệu và tuân thủ các quy định. Quyền riêng tư không phải là che giấu mọi thứ, mà là chỉ cho thấy những gì cần được hiển thị cho đúng những người cần phải xem.

Testing Rayls Sovereign's Zero Base Fee Claim Against EIP-1559
Brief answer
I wanted to know whether Rayls Sovereign’s documented gasless configuration keeps the base fee at zero indefinitely. Under the standard EIP-1559 calculation and parameters tested here, an above-target parent block makes the child base fee 1 wei, and subsequent empty blocks do not restore zero. A zero-priced transaction then fails the base-fee requirement. I have not established that production Sovereign uses that calculation and parameter set.
Axyl's execution code adds an important detail. The production fee-resolution path calls "compute_next_base_fee" when EIP-1559 is active. That function calls "calc_next_block_base_fee" and clamps the result to a configurable minimum using ".max(self.min_base_fee)". The chain-spec wrapper defaults this floor to "MIN_RAYLS_PROTOCOL_BASE_FEE", although its builder allows a different value.
The Sovereign documentation says gasless mode uses a zero floor, but I have not yet traced that setting to the production configuration or verified the underlying calculation function's implementation in this code path. A reader-run measurement of the public chain still points away from the bare per-block rule: its fee stayed at exactly 48 gwei across 300 near-empty blocks. My own tests cover the specification and the Alloy library's published vectors, not a running Axyl chain.
What I was trying to find out
Many institutions want a ledger where moving a token costs nothing. Free transactions remove the need to fund every employee wallet with a fee asset. They also remove the usual defense against spam, which is price. A gasless chain therefore has to explain how it stays gasless and how it stays usable.
Rayls Sovereign, the institution-run ledger, offers a gasless mode. The architecture page (modified 22 October 2026) says the mode is set at genesis and cannot change afterwards. It gives its reason in one sentence: because the EIP-1559 base-fee change is proportional to the parent base fee, a zero genesis fee and a zero floor "holds the base fee at zero indefinitely."
That is a mathematical claim, so I tried to check the mathematics.
The sentence rests on the word proportional. I went to the specification to see whether proportional is the whole rule.
The Axyl code shows why the configured floor matters. In "compute_next_base_fee", the current fee is taken from the parent header, falling back to "self.min_base_fee" if the parent has no base fee. When EIP-1559 is active, the code calls "calc_next_block_base_fee" and then applies ".max(self.min_base_fee)". Consequently, a zero minimum does not, by itself, prevent the calculation from returning 1 wei. Whether it does so depends on the underlying calculation and its parameters. The documentation's zero-floor explanation therefore needs to be assessed against both the calculation function and the actual gasless configuration.
Where the trail got complicated
Three Rayls statements about base fees need to be reconciled with the implementation. The Axyl Technical Specs (25 August 2026) say base fees are recalculated per block under the EIP-1559 rule, with its parameters recalibrated each epoch. The Axyl repository overview ("doc/index.md") says base fees remain constant within an epoch and are adjusted at epoch boundaries. The Why Rayls? page (24 August 2026) says fees are pegged to USDC.
The code adds a fourth piece of evidence: when EIP-1559 is active, "resolve_base_fee" calls "RaylsChainSpec::compute_next_base_fee", which calculates a next-block fee and applies a configurable minimum floor. This confirms that a per-block calculation path exists, but does not by itself establish whether epoch logic, a configured floor, or another setting determines the fee on a particular network. The gasless Sovereign configuration must be traced separately.
Per-block and epoch-constant updating require reconciliation if they describe the same mode and version. A USDC-denominated pricing objective could coexist with either. The inspected wrapper alone does not establish how these policies interact in gasless Sovereign.
What the specification says
EIP-1559 computes the next base fee from the parent block. The gas target is the block gas limit divided by an elasticity multiplier of 2. If the parent used exactly the target, the fee holds. If it used less, the fee falls by the parent fee times the shortfall, divided by the target and by 8. If it used more, the fee rises by the same expression, with a floor: the increase is at least 1 wei. The decrease has no such floor. A transaction is valid only if its max fee per gas is at least the block's base fee.
So proportional describes the decrease. The increase carries a one wei minimum that does not depend on the parent fee, and a zero parent fee is exactly the case where that minimum applies.
What I tested
I transcribed the update rule from the specification text into a short script and ran it from a zero base fee with an illustrative 100 million gas limit. Blocks at or below the target of 50 million keep the fee at 0. A block using the full 100 million moves it to 1 wei. After that, 1,000 empty blocks leave it at 1 wei, because the decrease on a 1 wei fee rounds down to nothing. A zero-priced transaction satisfies the base-fee pricing condition at base fee 0 and fails it at 1 wei. This comparison does not test its other validity requirements. From 1 wei, about 85 consecutive full blocks lift the cost of a 21,000-gas transfer past one gwei in total.
I then checked the script against code. The Axyl README says the execution layer is built on reth and alloy. In alloy-eips 2.5.0 (docs.rs, published 23 September 2026, linked under Sources at its pinned version), calc_next_block_base_fee adds the increase at lines 123 to 131 with a comment reading "Ensure a minimum increase of 1." The library's own test, calculate_base_fee_success at lines 207 to 237, includes a base fee of 0 with gas used above target producing 1, then 1 producing 2 and 2 producing 3. All ten vectors of that test are in the table below and in the script, which asserts each one and passes.
alloy-eips 2.5.0, src/eip1559/helpers.rs, test calculate_base_fee_success (elasticity 2, denominator 8)
# parent base fee gas used gas limit target next base fee branch
0 1,000,000,000 10,000,000 10,000,000 5,000,000 1,125,000,000 increase
1 1,000,000,000 10,000,000 12,000,000 6,000,000 1,083,333,333 increase
2 1,000,000,000 10,000,000 14,000,000 7,000,000 1,053,571,428 increase
3 1,072,671,875 9,000,000 10,000,000 5,000,000 1,179,939,062 increase
4 1,059,263,476 10,001,000 14,000,000 7,000,000 1,116,028,649 increase
5 1,049,238,967 0 2,000,000 1,000,000 918,084,097 decrease
6 1,049,238,967 10,000,000 18,000,000 9,000,000 1,063,811,730 increase
7 0 10,000,000 18,000,000 9,000,000 1 increase
8 1 10,000,000 18,000,000 9,000,000 2 increase
9 2 10,000,000 18,000,000 9,000,000 3 increase
One changelog entry touches this function. The alloy release notes list "fix(eip1559): prevent divide-by-zero in next base fee calculation" (pull request 3951) under v2.0.5, released 18 May 2026. The v2.5.0 notes, dated 23 September 2026, list no base-fee change, and the 2.5.0 source includes the fix. The pull request describes it as a defensive guard. In the source it is two early returns that hand back the parent base fee unchanged when the elasticity multiplier or the change denominator is zero, or when the gas limit is below the elasticity so the target rounds to zero, plus three regression tests at lines 367 to 387. It leaves the increase and decrease branches alone, so the one wei floor stands.
None of the ten vectors reaches the guard, because they use elasticity 2, denominator 8 and gas limits of at least 2,000,000, and the same test module repeats the 0, 1 and 2 inputs under four other parameter sets, each giving 1, 2 and 3. My script has no zero-parameter case and would raise a division error if the target were zero, where the library returns the parent fee.
Three limits apply to these results. First, I inspected Axyl's production fee-resolution path and chain-spec wrapper, but I have not verified the complete implementation of "calc_next_block_base_fee" or traced the gasless configuration to the code that constructs the production chain specification. Second, my simulation's 100 million gas limit is illustrative: I could not establish the Sovereign block gas limit or confirm its configured EIP-1559 parameters. Third, I have not run the calculation against a live Axyl node or verified the behavior of a running gasless Sovereign ledger
What the public chain adds
A reader ran a read-only script of mine against the Rayls public chain RPC (chain ID 72957, client version 1.4.1) it was a single run on 24th October 2026 at 2:10 am UTC. The public chain is not a gasless Sovereign ledger, so the result bears on Axyl's fee logic and says nothing directly about the gasless mode.
Across 300 blocks the base fee stayed at exactly 48 gwei, including across the boundary between epochs 176 and 177. The busiest block used 113,967 gas against a limit of 500,000,000, so every block sat far below the 250,000,000 target if the elasticity multiplier is 2. For an empty-block approximation starting at 48 gwei, using elasticity 2 and denominator 8, the standard rule falls below 1 gwei after 29 updates and eventually settles at 7 wei. This approximation is not a replay of the reader’s actual gas-use sequence. If the supplied consecutive-block records are accurate, they are inconsistent with the standard per-block update under elasticity 2 and denominator 8.
Several mechanisms could produce a constant fee, including epoch-based updating, a configured minimum or another custom policy. A library guard is relevant only if Axyl invokes that helper with triggering parameters; I established neither. These possibilities are not exhaustive. Epoch constancy alone would preserve zero within an epoch, not establish persistence across the boundary. The observed sequence therefore does not identify the Public Chain’s mechanism or determine Sovereign’s gasless behaviour.
The gas limit I could find
The one gas limit the Sovereign docs state belongs to a transaction.The execution code also shows that the next block's gas limit is taken from the canonical parent header, while the base fee is resolved separately through "gas::resolve_base_fee". This means the block's gas limit and the fee calculation are distinct inputs to block construction.
The Backend's fixed transaction gas limit of 5,000,000 must not be treated as the block gas limit or used to infer the EIP-1559 gas target.The Integrating Rayls Sovereign page (modified 6 October 2026) says the optional Backend builds every transaction with a fixed gas limit of 5,000,000 and takes the gas price from the chain's RPC. Neither that page nor the architecture page gives the block gas limit or the elasticity multiplier.
The Backend detail still matters. A Backend transaction asks the chain for its gas price, so it follows the fee wherever the fee goes. Two standard validity rules then apply. These are my reading of the usual rules, and no Rayls page states them. First, the transaction's max fee per gas must be at least the block's base fee, so a zero-priced transaction fails outright once the base fee is 1 wei, whatever the sender's balance.
Second, the sender's balance must cover the upfront cost, which is the gas limit times the max fee per gas plus any value transferred. For the Backend's 5,000,000 gas limit at 1 wei, that is at least 5,000,000 wei before any value, which a zero-balance account cannot meet even with a correctly priced transaction. Besu documents disabling a transaction-pool balance check in free-gas configuration. That admission setting does not itself establish that execution permits an otherwise unaffordable positive-fee transaction. I did not establish whether Axyl modifies either layer.
How Besu solves the same problem
Besu's free gas guide (retrieved 25 October 2026) treats gasless as a configuration. For a network on London or later, it says the operator must also enable zeroBaseFee on every node, set the minimum gas price to zero, and turn off the transaction pool balance check so zero-balance senders pass. It gives the reason: London introduced a non-zero base fee, which normally means transactions need gas.
The difference.
Besu turns the base fee off with an explicit switch and lists the other settings that must agree. The Rayls page relies on arithmetic and a floor parameter.
Why it matters.
Both configurations and formulas can be tested. Besu names an explicit free-gas switch; the reviewed Rayls explanation does not identify the additional behaviour needed to preserve zero under above-target load.
The trade off:
Besu needs every node configured identically, and it's guide warns that a node with a higher minimum gas price silently drops zero-price transactions.
Rayls documents gasless mode as fixed at genesis. Whether its implementation preserves zero under load and across epoch boundaries remains unverified.
What changes in practice.
A Besu operator audits a short checklist. A Rayls operator should inspect the applicable fee code and test a recorded gasless configuration under above-target load and across an epoch boundary before promising permanent gaslessness
Takeaway
The inspected wrapper applies a minimum to the calculated fee; setting that minimum to zero does not suppress a positive result. Standard EIP-1559 produces such a result after an above-target parent block. Rayls’ zero-forever explanation therefore requires an additional implementation or configuration justification. Whether production Sovereign provides it remains unverified. Completing the check requires a pinned source revision, the applicable helper and configuration, and tests under above-target load and across an epoch boundary.
@Rayls

Câu trả lời ngắn gọn
Tôi muốn biết một ngân hàng nhận được gì khi một blockchain tuyên bố có “tính chung cuộc tất định dưới một giây”, và giây đó được tính theo đồng hồ nào. Với cơ chế đồng thuận Axyl của Rayls, theo cách tôi hiểu thì câu trả lời gồm hai phần. Thiết kế này là một giao thức chịu lỗi Byzantine có thể đảm bảo tính chung cuộc tất định: một khi lớp đồng thuận xác nhận một giao dịch, các nút trung thực sẽ thống nhất về vị trí của giao dịch đó, miễn là chưa đến một phần ba quyền biểu quyết của ủy ban gặp lỗi. Tôi không tìm thấy định nghĩa được công bố về thời điểm mà ứng dụng phía khách có thể coi một giao dịch là chung cuộc. Tôi cũng không thể đọc các số liệu chuẩn làm cơ sở cho tuyên bố “dưới một giây”, vì chúng nằm trong hình ảnh.

EVM riêng tư là một chuỗi tương thích với Ethereum nhưng không phải mạng Ethereum công khai: cùng bytecode, cùng hợp đồng Solidity, cùng công cụ dành cho nhà phát triển, nhưng được vận hành bởi một tổ chức hoặc một nhóm nhỏ các tổ chức, mặc định không cho công chúng đọc dữ liệu trên đó. Các ngân hàng đặc biệt muốn có giải pháp này để có thể tái sử dụng những mẫu hợp đồng thông minh đã được kiểm toán suốt một thập kỷ và tuyển dụng nhà phát triển theo cách thông thường mà không công khai mọi giao dịch cho các đối thủ cạnh tranh. Phần đó khá đơn giản.
Điều khiến tôi bắt đầu tìm hiểu là một sự thật cụ thể: Hyperledger Besu, phần mềm mà Rayls' own Private Network Hub vận hành trên đó, đã có sẵn tính năng tích hợp để thực hiện chính xác việc này. Thế nhưng Rayls lại xây dựng một giải pháp khác. Tôi muốn biết lý do.

Tôi bắt đầu tìm hiểu chỉ một điều duy nhất: ai có thể thêm một ngân hàng mới vào Rayls Private Network. Câu trả lời ban đầu hóa ra đúng nhưng chưa đầy đủ, và phần còn thiếu lại nằm trên một trang mà các công cụ tìm kiếm không lập chỉ mục.
Trang tổng quan Sovereign của Rayls, được cập nhật ngày 17 tháng 9 năm 2026, mô tả Rayls Private Network là “có cấp quyền truy cập, do các tổ chức tham gia quản lý”. Số nhiều. Trái lại, trang riêng về vai trò của Rayls nói rõ ai thực sự vận hành mạng: “Operator là cơ quan có thẩm quyền của Private Network. Họ cài đặt Private Network và chỉ họ mới có quyền thực thi cơ chế quản trị.”