Search for projects by name
LightLink is a project that lets dApps and enterprises offer users instant, gasless transactions. It aims at becoming an Ethereum Layer 2.
LightLink is a project that lets dApps and enterprises offer users instant, gasless transactions. It aims at becoming an Ethereum Layer 2.
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
There is no mechanism to have transactions be included if the sequencer is down or censoring.
Currently the system permits invalid state roots. More details in project overview. State updates must be signed by at least 50.00% of validators, which corresponds to a minimum of 2 validators.
Proof construction and state derivation fully rely on data that is posted on Celestia. Sequencer tx roots are not checked against the Blobstream bridge data roots onchain, but L2 nodes can verify data availability by running a Celestia light client.
There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
LightLink chain state roots are periodically posted to Ethereum through a CanonicalStateChain contract on L1. After the challenge window of 3d, the published state root is assumed to be correct. During the challenge window, anyone can challenge a block header against some basic validity checks. The challenge fee required is 1.5 ETH. Once challenged, the permissioned defender can respond within 2d to the challenge, by providing the L2 header and the previous L2 header. If the defender does not respond, the block header is considered invalid, the canonical state chain is rolled back to the previous state root, and the challenger can claim back the challenge fee. If the defender successfully responds, the challenger loses the challenge fee to the defender. Since only the block header can be challenged and not the state transition, the system is vulnerable to invalid state roots. Moreover, state roots are not used for L1 bridge withdrawals. Users can deposit tokens on the LightLink chain by sending them to the L1BridgeRegistry contract on Ethereum L1. On the LightLink chain, token minting is then authorized by a permissioned set of signers providing signatures as input to the syncDeposit() function on the L2ERC20Predicate contract. Users can withdraw their funds by submitting a withdraw() transaction to the L2ERC20Predicate contract, which will burn the tokens on the LightLink chain. To then unlock tokens from the bridge on L1, a validator multisig needs to validate the withdrawal based on off-chain validity checks. Users can exit the network once enough validators have signed off on the withdrawal. Currently, a minimum of 2 validators is required to sign off on a withdrawal.
Users can be censored if validators decide to not mint tokens after observing an event on Ethereum.
Funds can be stolen if validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum.
Funds can be stolen if validators relay a withdraw request that wasn't originated on the source chain.
Tokens on the destination end up as wrapped ERC20 proxies that are upgradable by the LightLinkMultisig, using EIP-1967.
Funds can be stolen if destination token contract is maliciously upgraded.
Permissioned set of actors that can validate withdrawals from the bridge. Each validators has a voting power assigned that determines the weight of their vote. Currently, the threshold is set to 50.00% of the total voting power.
The proposer (“publisher”) is responsible for pushing new state roots to the CanonicalStateChain contract on L1.
This address is the admin of the L1BridgeRegistry. It can pause the bridge and upgrade the bridge implementation. It also determines the validators of the bridge and their voting power. It is not a Gnosis Safe multisig, but a custom multisig implementation.
This address is the owner of all the CanonicalStateChain and Challenge contracts. Can replace the proposer and core system parameters.
The Canonical State Chain (CSC) contract is the main contract of the LightLink network. It stores the state roots of the LightLink chain on Ethereum L1.
Upgrade delay: No delay
The Challenge contract is used to challenge block headers on the LightLink chain. Currently, data availability challenges and execution challenges are not enabled.
Upgrade delay: No delay
The L1BridgeRegistry contract is used to store the address of the LightLink multisig and the address and voting power of the validators managing the bridge.
If the DAOracle is set, this contract enables any user to directly upload valid Layer 2 blocks from the data availability layer to the L1.
Upgrade delay: No delay