NurseeGabriel

Kebanyakan proyek Blockchain hanya mengatakan Kutip "kami telah memproses jutaan transaksi"
Betul .. itu adalah pencapaian kunci, tetapi pertanyaannya adalah BAGAIMANA PARA PENGGUNA TAHU apakah klaim-klaim tersebut benar ? Itu masalahnya!.
Pertanyaan ini menuntut sebuah jawaban, dan jawabannya adalah solusi .Di sinilah RAYLS berperan.
Sekarang .. mari kita uraikan
RAYLS melalui pendekatan inovatifnya menghadirkan model Transparansi dan kerangka kerja pembuktian penggunaan. Tapi pertama-tama, mari kita pahami konsep pembuktian penggunaan yang dibawa oleh Rayls.

Adopsi Blockchain oleh bank dan institusi keuangan lainnya melakukan restrukturisasi lainnya
Inilah alasannya
Tantangan adopsi Blockchain saat ini oleh Bank dan institusi keuangan lain yang teregulasi adalah PRIVASI.
Meskipun Blockchain mempertahankan gaya konvensionalnya dalam transparansi dan imutabilitas ... bank-bank dan institusi keuangan lain tersebut menghadapi tantangan dalam perlindungan informasi pelanggan, data, dan kepatuhan terhadap peraturan. Privasi Bukan tentang menyembunyikan segalanya, melainkan tentang Menampilkan hanya apa yang perlu ditampilkan kepada hanya mereka yang perlu melihatnya.

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

Jawaban singkat
Saya ingin tahu apa yang didapat bank ketika sebuah rantai mengiklankan “finalitas deterministik di bawah satu detik”, dan berdasarkan jam apa hitungan detik itu berjalan. Untuk konsensus Axyl dari Rayls, menurut pemahaman saya, jawabannya terbagi dua. Desainnya adalah protokol toleran terhadap kesalahan Bizantium yang dapat memberikan finalitas deterministik: setelah lapisan konsensus mengonfirmasi sebuah transaksi, node yang jujur sepakat mengenai posisinya, selama kurang dari sepertiga kekuatan suara komite mengalami kesalahan. Saya tidak menemukan definisi yang dipublikasikan tentang kapan klien boleh menganggap sebuah transaksi final. Saya juga tidak dapat membaca angka tolok ukur di balik klaim “di bawah satu detik” karena angka-angka tersebut ditampilkan dalam gambar.

EVM privat adalah blockchain yang kompatibel dengan Ethereum, tetapi bukan jaringan Ethereum publik: bytecode yang sama, kontrak Solidity yang sama, perangkat pengembangan yang sama, tetapi dijalankan oleh sebuah institusi atau sekelompok kecil institusi, dengan akses baca publik yang secara default dibatasi. Bank menginginkan ini secara khusus agar dapat menggunakan kembali pola kontrak pintar yang telah diaudit selama satu dekade dan merekrut pengembang seperti biasa, tanpa mengumumkan setiap transaksi kepada pesaing. Bagian itu sederhana.
Ada satu fakta spesifik yang mendorong saya mencari tahu: Hyperledger Besu, perangkat lunak yang menjalankan Private Network Hub milik Rayls, sudah dilengkapi fitur bawaan untuk melakukan hal ini persis. Namun, Rayls justru membangun sesuatu yang lain. Saya ingin tahu alasannya.

Saya mulai mencari satu fakta saja: siapa yang dapat menambahkan bank baru ke Rayls Private Network. Jawaban awal ternyata benar, tetapi belum lengkap, dan bagian yang hilang itu ternyata ada di halaman yang tidak diindeks mesin pencari.
Ikhtisar Sovereign umum Rayls, yang diperbarui pada 17 September 2026, menjelaskan Rayls Private Network sebagai "berizin, dikelola oleh institusi yang berpartisipasi." Bentuk jamak. Sebaliknya, halaman peran khusus Rayls menjelaskan dengan tegas siapa yang sebenarnya menjalankan jaringan tersebut: "Operator adalah otoritas Private Network. Mereka memasang Private Network dan hanya mereka yang berwenang menegakkan tata kelola."