Sayfa çevriliyor.
Sıradaki bölüm hazırlanıyor…
Şşşt… okumayı kendine göre düzenle.
Yazı tipleri ve temalar Görünüm içinde. Gözlerinin de söz hakkı var.
Sıradaki bölüm hazırlanıyor…
A public Ethereum zkEVM rollup powered by the Lineth software stack, with execution on Layer 2 and validity proofs and settlement on Ethereum.
Tarayıcının sesli okuma desteği kontrol ediliyor…
Bu okuma şu anda İngilizce mevcut. Arayüz seçtiğin dili kullanıyor.
İngilizce özgün metni oku →Linea Mainnet is a specific public network; Lineth is the configurable rollup software that powers it. The distinction prevents a misleading assumption that every deployment of the software publishes data or settles in the same way. In the documented Linea configuration, sequencer components build Ethereum-compatible blocks, a state manager maintains information used in proving, and a coordinator groups work and submits proofs. Ethereum contracts verify those proofs and record the resulting state commitments.
The supporting components perform different jobs rather than constituting one interchangeable validator role.
A transaction first receives confirmation within Linea. Later, a proof covering its batch is verified on Ethereum, and the Ethereum block containing that verification must itself finalize. Linea documentation calls these soft and hard finality. For an application that needs Ethereum settlement, the latest visible block is therefore a different reference from the finalized block. The documented finalized RPC tag provides a concrete way to inspect that distinction. Proving and batching time can vary, so a historical average should not be treated as a guaranteed withdrawal deadline.
Linea's published risk disclosures discuss operator availability, bridge contracts, software defects, and administrative powers alongside the proof system. Those are separate questions from whether a proof mathematically verifies execution. A proof does not stop an upgrade authority from changing the verifier or other system contracts where that authority exists. It also cannot force an unavailable service to answer immediately.
When checking a deployment, examine its current contracts and controls as well as the proof design, and distinguish descriptions of launch conditions from subsequently activated upgrades.