Draft
Conversation
## Summary - Add `build-exporter-image.yaml` for GCP Cloud Build to build the linera-exporter Docker image - Refactor `docker_image.yml` workflow: - Extract `BUILD_TIMEOUT` and `BUILD_MACHINE_TYPE` to env vars for easier configuration - Create `submit_build()` function to reduce code duplication - Use descriptive variable names (`BUILD_ID_LINERA` vs `BUILD_ID_1`) ## Test plan - [ ] Verify workflow syntax is valid - [ ] Test on a `devnet_*` or `testnet_*` branch push - [ ] Confirm exporter image is built and pushed to `us-docker.pkg.dev/linera-io-dev/linera-public-registry/linera-exporter`
## Motivation
All chains in the wallet are currently fully synchronized, including
their sender and publisher chains. But in use cases where the user only
wants to _read_ from that chain and not _write_ to it (i.e. never make a
block proposal, e.g. because they don't even own it), sender and
publisher chains are not needed, and neither are the chain manager
values.
## Proposal
Add a new listening mode and flag that marks chains as "follow-only".
For those chains, only their own confirmed blocks are synchronized.
The `follow-chain` and `forget-keys` commands automatically set that
flag, and `assign` unsets it.
## Test Plan
A test was added.
## Release Plan
- These changes could possibly be backported to `testnet_conway`, then
- be released in a new SDK.
## Links
- Closes #5098.
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation #3651 ## Proposal Introduce a thread pool on top of `web-thread` and reüse a fixed pool of threads (here hardcoded to 20, without any particular rationale; we should make it configurable as future work). ## Test Plan CI. The pool logic is shared between the native and Web cases, so should be adequately tested by our usual end-to-end tests. ## Release Plan - These changes should be backported to the latest `testnet` branch, then - be released in a new SDK, ## Links - fixes #3651 - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation
We have a `BaseRuntimeApi::log` endpoint that when called from a
contract will log to the stdout. This leads to massive amounts of logs
on validators.
## Proposal
Support opt-in enabling of the feature.
This is achieved by adding a boolean, config flag to
`ExecutionRuntimeConfig` which is then accessed from within the
`BaseRuntimeApi`.
## Test Plan
Manual
```
➜ linera-protocol git:(testnet_conway) ✗ ./target/debug/linera --contract-logs wallet follow-chain 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf --sync
2025-12-09T11:55:17.268236Z WARN handle_chain_info_query{address="https://linera-testnet.runtime-client-rpc.com:443"}: grpc_client: error=Blobs not found: [BlobId { blob_type: ChainDescription, hash: 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf }]
2025-12-09T11:55:17.311762Z WARN handle_chain_info_query{address="https://linera.everstake.one:443"}: grpc_client: error=Blobs not found: [BlobId { blob_type: ChainDescription, hash: 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf }]
2025-12-09T11:55:18.480625Z INFO linera_execution::wasm::runtime_api: Fund success transfer_id 1985 fund type Swap on chain 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf
^C
➜ linera-protocol git:(testnet_conway) ✗ ./target/debug/linera wallet follow-chain 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf --sync
2025-12-09T11:55:34.824419Z WARN handle_chain_info_query{address="https://linera-testnet.runtime-client-rpc.com:443"}: grpc_client: error=Blobs not found: [BlobId { blob_type: ChainDescription, hash: 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf }]
2025-12-09T11:55:34.862661Z WARN handle_chain_info_query{address="https://linera.everstake.one:443"}: grpc_client: error=Blobs not found: [BlobId { blob_type: ChainDescription, hash: 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf }]
2025-12-09T11:55:41.903767Z WARN handle_chain_info_query{address="https://linera-testnet-validator.contributiondao.com:443"}: grpc_client: error=Blobs not found: [BlobId { blob_type: ChainDescription, hash: 6dbf54bd5dfb29560c7911f3e6763bb8c792da46f604f3d2b6b52a91521a9edf }]
```
## Release Plan
- These changes follow the usual release cycle.
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
- be released in a validator hotfix.
## Links
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
…ssages. (#5105) ## Motivation Keeping track of the `unskippable_bundles` collection seems to significantly increase the overhead for cross-chain messaging, as observed in the benchmarks. ## Proposal Remove it. Enable fallback mode based on epochs only, not based on tracked or protected messages. ## Test Plan The fallback test was updated. ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - Closes #5103. - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Summary - Add dedicated `image` and `imagePullPolicy` configuration for `blockExporter` in the Helm chart - Block exporter now uses its own image instead of reusing the indexer image - This allows independent versioning of the block exporter container ## Changes - `kubernetes/linera-validator/values.yaml`: Added `blockExporter.image` and `blockExporter.imagePullPolicy` - `kubernetes/linera-validator/templates/block-exporter.yaml`: Changed from `indexer.image` to `blockExporter.image` ## Testing - Helm template renders correctly with new values - Requires corresponding lineractl changes (linera-infra PR)
## Motivation
Signing blocks on the Web can get tiresome when using wallets like
MetaMask or Dynamic, since we aren't integrated with their autosigning
features, and working with chains with hundreds of incoming messages
typically means accepting hundreds of signatures.
## Proposal
First connect to the ‘real’ wallet, and use it to sign a block that adds
a new local keypair as an additional owner of the chain. Then, replace
the original owner of the chain with this new temporary owner in the
wallet so that future blocks will be signed with that key instead. We
currently keep the wallet in memory on the Web so needn't worry about
overriding the real owner.
This is a slightly clumsy approach (and the application must be careful
to send any assets back to the original owner!) but should work as a
first step.
Implement a little supporting API to the Web client, then demo an
autosigning flow in the MetaMask counter demo.
## Test Plan
Tested by hand.
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
- be released in a validator hotfix.
## Links
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation By default we compile with stable Rust, but the Web build requires nightly for (unstable) Wasm threading support. Under `rustup` we have the `rustup` `rust-toolchain.toml` files such that entering the `web` directory automatically changes the default Rust toolchain. However, we don't have a parallel flow when using Nix. I would like to parse the `rustup` configuration files from `nixup`, but the semantics of finding the right toolchain (`rustup` just downloads one into the user's home directory!) are a little involved and I haven't been able to prioritize it. ## Proposal Add an extra `.envrc` file for now that sets `RUST_TOOLCHAIN=nightly` in the `web` directory. ## Test Plan Tested locally. ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation Application logs (via `log::info!()` etc.) were not appearing in the browser console when running Linera in the web client. Neither was the output of: `println!`, `tracing!`, `web_sys::console::*` or even `panic!`. ## Proposal Contract execution in the browser happens inside a Web Worker. Web Workers have isolated JavaScript contexts - they don't share the browser's console. Direct calls to `web_sys::console::log_1()` or `js_sys::eval()` from within the worker context don't reach the browser's developer console. Forward log messages from the worker to the main thread through the existing `ExecutionRequest` channel that's already used for worker-to-main-thread communication. On the main thread, output logs directly to `web_sys::console` with clean formatting (`[CONTRACT INFO]` message). Happens only for `#[cfg(web)]`, native works as it used to. ## Test Plan Manual <img width="835" height="171" alt="Screenshot 2025-12-12 at 16 48 23" src="https://github.com/user-attachments/assets/d97bfc75-6a78-4139-9f05-7f0842ca709e" /> ## Release Plan - These changes should be backported to `testnet` branch, and then - be released in a new SDK, ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
Owner
Author
|
Hi maintainers 👋 Could you please advise on how to contribute Thanks! |
## Motivation @afck pointed out that having a lot of owners with non-zero weights would slow the chain down in single-leader rounds. @ma2bd pointed out that we need to make mutations using the original owner. ## Proposal Add a `weight` option to `addOwner` in an options object, and default it to zero. Add an optional `owner` option to `query` in an options object, and use it to sign mutations. Also, document the above inline. ## Test Plan Tested locally. Also, CI should test some of the API (but sadly not yet as much as we'd like it to). ## Release Plan - These changes should be backported to the latest `testnet` branch, then - be released in a new SDK, ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation We have several internal and external use cases for dealing with more than one chain at once. ## Proposal Add chain-specific API, and have `Client` only initialize the client rather than creating a default chain. This provides a place to put the (currently hardcoded) client options, which I do, closing #4740. ## Test Plan Tested locally on all our Web examples. ## Release Plan - These changes should be backported to the latest `testnet` branch, then - be released in a new SDK, ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation
I left a spoon in the pie.
## Proposal
Extract.
## Test Plan
None.
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
## Links
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation
Now we're typechecking better it becomes clear that some of our
TypeScript types are not correct.
In the build step for `linera-web` we accidentally erase some types (as
`tsc` doesn't preserve `.d.ts` files).
`tsify-next` assumes the structure of our JavaScript types based on the
Rust type structure even though we serialize some types as strings.
## Proposal
Copy the `.d.ts` files directly without letting `tsc` touch them.
Then, use `tsify`'s (`tsify-next` now being obsoleted) `type` attribute
to provide type overrides for the string-serialized types.
## Test Plan
Currently testing manually with the examples.
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
## Motivation Make CI green again ## Proposal deactivate benchmarks in CI ## Test Plan CI
## Motivation
Shards can occasionally become completely unresponsive due to, for
example, deadlocks or livelocks. When this happens, the pod can stay
"Running" but for example accepts no connections, requiring manual
intervention to detect and restart.
## Proposal
Add TCP liveness probes to proxy and shard pods so Kubernetes
automatically restarts unresponsive pods.
## Test Plan
Deployed a temporary network with these changes to make sure everything
seems to work
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a validator hotfix.
## Motivation
We are seeing `TRACE` level logs in the web console. They are very
spammy and are potentially slowing down the app.
## Proposal
Cap the level to `DEBUG` for Linera web client.
## Test Plan
Manual.
## Release Plan
- These changes should
- be released in a new SDK,
## Links
#5175
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation
Some types are now duplicated between `linera_service` and the
`task_processor` in `examples`.
## Proposal
Move the duplicated types to `linera_base`, re-export them from
`linera_sdk`.
## Test Plan
CI
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
## Links
- closes #5176
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation
The Docker Compose validator setup has a bug: all 4 shard containers run
with --shard 0 instead of each having a unique shard number (0, 1, 2,
3). This causes inter-shard communication to fail because all shards are
configured identically rather than as distinct shards of the validator.
Additionally, the proxy health check was checking port 19100, which is
an internal port. Checking on port 21100 instead, which is for metrics.
## Proposal
1. Fix shard configuration: Replace the single shard service using
replicas: 4 with 4 separate services (shard-0, shard-1, shard-2,
shard-3), each with the correct --shard argument. Docker Compose's
replicas feature doesn't support per-replica command arguments, so
separate service definitions are required.
2. Fix proxy health check: Change the health check port from 19100 to
21100 (the metrics port that the proxy actually listens on).
3. Update alloy override: Update docker-compose.alloy.yml dependencies
to reference the new shard service names.
## Test Plan
- Deployed the fix to the OVH docker compose validator
(ovh-or1-compose-validator-01)
- Verified all 4 shards start with correct shard numbers (0, 1, 2, 3)
- Verified inter-shard connectivity works
- Verified proxy health check passes
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a validator hotfix.
## Motivation
We are synchronising sender chains that we shouldn't be b/c they're
sending messages to a chain we follow in `FollowOnly` mode.
## Proposal
Filter out chains which we don't follow in `FullChain` mode.
## Test Plan
manual.
## Release Plan
- These changes should be
- be released in a new SDK,
- backported to `main`
## Links
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation `cargo install --path linera-service --bin linera --debug` [fails](https://github.com/linera-io/linera-protocol/actions/runs/20711224126/job/59451976233): It uses `async-graphql-value-7.1.0`, which requires a newer Rust version. Also `test_project_new` fails, for the same reason. ## Proposal Use `--locked` in the docker compose build, pin async-graphql-value to version 7.0.17. ## Test Plan I tried it locally. After this PR, I'd expect the `compose` check to pass again in CI. ## Release Plan - These changes should be backported to `testnet_conway`, then - be released in a new SDK. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
…ages (#5189) ## Motivation Right now if we create a chain in message which is processed in `handle_received_messages` , we cannot get the `ChainDescription` of the created chain. ## Proposal Returns the generated block from `handle_received_messages` then unit tests can get `ChainDescription` from the block. ## Test Plan CI ## Release Plan These changes follow the usual release cycle --------- Signed-off-by: Zhao KK <kikakkz@hotmail.com>
## Motivation In previous work, the ability to create an EVM contract was introduced. We already had the functionality of calling an EVM contract from another EVM contract. So, it was reasonable to think that the created contract B from contract A could be called from contract A. That is not so. The contract had to be registered. ## Proposal Add the registration of the created contract to the journal (this was found by extensive interaction with Claude). ## Test Plan Add the calls of contract B from contract A. This has been combined with calls directly to contract B. Then the values are checked by service queries. ## Release Plan I would support enabling EVM in TestNet Conway. ## Links None.
Port of #5201. ## Motivation We want an option to run the node service so that it can be publicly used for queries, but not for mutations. ## Proposal Add a `--read-only` option. (Based on #5196; I added a test with Claude's help.) ## Test Plan A test was added. ## Release Plan - Nothing to do. ## Links - PR to main: #5201. - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Mathieu Baudet <1105398+ma2bd@users.noreply.github.com>
## Motivation
We have this for single blocks, but not for multiple.
## Proposal
Create the multiple blocks version
## Test Plan
CI
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a validator hotfix.
## Motivation #5142 only solved the issue for one type of tests. ## Proposal Only CLI users want logs disabled by default. ## Test Plan tested manually ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) Backport of #5197 Co-authored-by: Mathieu Baudet <1105398+ma2bd@users.noreply.github.com>
## Motivation The `send_chain_information` method in `linera-core/src/updater.rs` had grown into a complex, monolithic function that was difficult to understand and maintain. The method handled multiple distinct responsibilities (height synchronization, round synchronization, chain initialization) in a single 150+ line function with limited documentation. ## Proposal This PR refactors the `send_chain_information` method to improve code clarity and maintainability through: 1. **Comprehensive documentation**: Added detailed doc comments explaining the two-phase synchronization strategy (height sync followed by round sync) 2. **Method decomposition**: Split the monolithic function into four focused methods: - `sync_chain_height`: Synchronizes a validator to a specific block height using an optimistic approach (send last certificate first, fill gaps if needed) - `initialize_new_chain_on_validator`: Handles the special case of validators that don't know about a chain yet - `sync_consensus_round`: Synchronizes consensus round state at a given height - `send_chain_info_for_blobs`: Sends chain information for chains referenced by blobs (deduplicates previously repeated logic) 3. **Improved error handling**: Made round synchronization more resilient by treating failures as non-fatal (logs debug messages instead of propagating errors), since height sync is the primary objective 4. **Better logging**: Added more descriptive debug messages throughout the synchronization process to aid debugging This is a pure refactoring with no functional changes to the synchronization protocol or behavior. ## Test Plan - CI ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) Backport of #5205
## Motivation Clippy warnings have to be as strong as possible. Fixes #5573 ## Proposal Add it to `Cargo.toml` and address the issues that show up. ## Test Plan CI ## Release Plan This kind of things could be backported to `testnet_conway` but we have probably more important things to do. ## Links None
## Motivation The `write_batch` of `fn save()` derive implementation of the `RootView` trait is followed by a `post_save`. This does not make sense for the smart contract which takes `mut self` as input. Fixes #4976 ## Proposal Introduce a `fn save_and_drop(self)` function to the trait and implement it. It turns out that there is no other use case than the smart contract where we consume a view and write it. ## Test Plan CI ## Release Plan It could definitely be backported to `testnet_conway` as it lead to a small gas reduction. ## Links None.
## Motivation If a client listens only to events from a chain, and builds a sparse event chain this way, then restarts the service, the restarted service will attempt to synchronize the whole chain, filling in all the gaps and defeating the purpose of a sparse chain. ## Proposal Do not synchronize chains we listen to in `EventOnly` mode. Instead, when a new event arrives, check that the block that has emitted the previous event is present. If not, synchronize that block and repeat. This has the disadvantage that we won't synchronize missing events until a new one appears, so a better solution might be needed. Written partially by Claude. ## Test Plan CI An existing test has been modified to showcase the issue. It is failing without the fix, and passing with the fix. ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Motivation The chain actors are complicated and unnecessary, and even read-only requests to them are unnecessarily run only sequentially. ## Proposal Remove the chain actors, use an `RwLock` instead. ## Test Plan CI should catch regressions. We should do benchmarks to see if this improves performance. ## Release Plan - Backport to `testnet_conway`. - Release a new SDK. ## Links - Closes #5536, #2447, #2237, #3299 - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Motivation Users that claim a chain from the faucet should receive tokens daily, so they can use the testnet indefinitely and pay the fees. ## Proposal Add daily claims, similar to `pm-faucet`. ## Test Plan A unit test was added. ## Release Plan - Backport to `testnet_conway`. - Update the faucet. ## Links - Closes #5556. - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Motivation It would be nice to be able to query a chain without opening a node-service. Fixes #5279 ## Proposal Add a function to the `linera` for doing exactly that. Add it to the client as well. Note that the design somehow assumes that the smart contract being accessed is processing a GraphQL query. ## Test Plan CI. An additional test is added to `test_wasm_end_to_end_counter`. ## Release Plan This could be backported to `testnet_conway`. ## Links None.
) ## Motivation `retry_pending_cross_chain_requests` was silently dropping `NewIncomingBundle` notifications returned by `handle_cross_chain_request`. This could potentially cause dropped notifications when concurrent paths (e.g. validator notification streams) triggered cross-chain delivery through this method. ## Proposal Don't drop these. ## Test Plan CI It's unclear if this was actually a problem, and related to some of the flaky tests we're seeing. ## Release Plan - Backport to `testnet_conway`. ## Links <!-- Optional section for related PRs, related issues, and other references. If needed, please create issues to track future improvements and link them here. --> - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Port of #5666. ## Motivation `update_from_info` can clear the pending block proposal while `execute_block` is ongoing, because it doesn't lock the `client_mutex`. ## Proposal Unify both into a single `Arc<Mutex<Option<PendingProposal>>>` per chain. The mutex now both serializes proposals and holds the pending proposal, ensuring all reads/writes are synchronized. Remove `update_from_info` (which only cleared stale proposals), `update_state`, `clone_for_update_unchecked`, and inline `process_certificate` into its call sites. ## Test Plan CI This should fix the (rare and hard to reproduce) race condition. ## Release Plan - Nothing to do. ## Links - Fixes #5664. - Testnet version: #5666 - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Motivation CI is failing because some dependencies require Rust > 1.86.0 now. ## Proposal Pin the versions of these dependencies in `Cargo.toml.template`. ## Test Plan CI should be green now. ## Release Plan - Backport to `testnet_conway`. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation The function `fn process_cross_chain_update` of `linera-core/src/chain_worker/state.rs` is reading rhe inbox of origin three times: * In next_block_height_to_receive (1 time) * In last_anticipated_block_height (1 time) * In receive_message_bundle (as many times as the number of bundles) Another issue is the `NUM_INBOXES` metric being called in the hot path. The does a `inboxes.count()` which is an expensive operation. This is inefficient. ## Proposal Access the inbox directly in `process_cross_chain_update` and pass it around. We could not do it for receive_message_bundle. Put a single emission of `NUM_INBOXES` when we did a `try_load_all_entries`. ## Test Plan CI ## Release Plan Can be backported to `testnet_conway` since this is strictly a change to the ordering of operations. ## Links None.
## Motivation We'd like to know if we accidentally break the Web examples. ## Proposal Move the script for the Web examples out of the HTML file and into a separate `script.ts`. This is sad, because it makes the example less self-contained, but I don't know how to persuade `tsc` to check the contents of a `<script>` tag/Vite to produce an extracted version that `tsc` can check. Make some alterations to make it typecheck (I guess it didn't before!). Add Playwright tests for basic example functionality. Add application deployment and run the tests on CI, in `web.yml`. ## Test Plan The CI for this PR :) ## Release Plan - These changes should be backported to the latest `testnet` branch ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation Chains with many interacting origins accumulate `InboxStateView` entries, most of which are empty. This makes processing pending message bundles very inefficient since `try_load_all_entries()` loads every inbox. ## Proposal Add a `nonempty_inboxes` set (mirroring the existing `nonempty_outboxes` pattern) so that only inboxes with pending added bundles are loaded. ## Test Plan CI should catch regressions. We could try and do benchmarks first, or just see if it resolves the performance issue (#5700) we see on the testnet. ## Release Plan - Backport to `testnet_conway` with a `bool` that tells us if the collection has been initialized. (So old chain state views can be loaded correctly.) - Release a new SDK. ## Links - Part of #5700 (but needs backport) - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Motivation The repeated transfers test is repeatedly failing on CI: * `test_end_to_end_repeated_transfers`: For notifications issues * `test_project_new` / `test_project_publish`: because we are only using 1.86 ## Proposal Disable them. ## Test Plan CI ## Release Plan Not relevant. ## Links None.
## Motivation The metrics need to be handled carefully: * They should not be in the hot path. * Calling the metric should be cheap and not be a big computation. ## Proposal Move the metrics for inbox/outbox out of the critical path and make them async by computing the size from the nonempty boxes. ## Test Plan CI ## Release Plan Could be backported to `testnet_conway`. ## Links None
## Motivation The native fungible officially supported the allowances but in practice not as the functionality was not present. This needed to be corrected. Fixes #4968 ## Proposal Straightforward implementation ## Test Plan The same framework that supports the allowances for `fungible` also support `native-fungible`. ## Release Plan Supporting such a functionality in testnet_conway is not exactly impossible but would require some works. ## Links CI.
## Motivation The function `fn count` of `ReentrantCollectionView`, `CollectionView`, `MapView`, and `SetView` has a misleading name that could imply that it is cheap. It is not since they all have a `find_keys_by_prefix` operation underlying them at a minimum. ## Proposal Rename it to `iterative_count` ## Test Plan CI ## Release Plan Can be backported to `testnet_conway`. ## Links None.
## Motivation The GRPC does support notifications, but `simple` does not. It is true that we use simple very little in comparison with GRPC. However, there is no valid reason for not supporting notifications. Also, extending the test surfaces should allow detecting more problems. ## Proposal Straightforward implementation. ## Test Plan One test was added to the CI for `retry_notification`. But no tests were added for the repeated transfers, which maybe we should have done. ## Release Plan Could be backported to `testnet_conway`. ## Links None.
Port of #5711. ## Motivation In the backport #5711 of #5611 some simplifications were made that were not present in #5611. ## Proposal Port those back to `main` again. ## Test Plan CI ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - Follow-up to #5611. - Port of #5711. - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Motivation Clippy is a very useful tool for reducing the complexity of the code and avoiding bad rust code. Fixes #5573 ## Proposal Implement a bunch of additional clippy corrections. ## Test Plan CI ## Release Plan This could be backported to the testnet_conway if there is demand. ## Links None.
## Summary - Fix `values-local.yaml.gotmpl` defaulting to the Alloy OTLP URL even when `otel_endpoint` is null in network properties - The `| default` fallback bypassed the Rust-side guard (`otel_endpoint.is_some()`) by filling in the Alloy endpoint when the env var was unset - Now gates the entire OTLP endpoint block on `$explicitEndpoint` being set — when unset, always emits empty string to disable tracing ## Test plan Ran `lineractl sync` with `otel_endpoint: null` in network properties and confirmed the diff no longer sets `LINERA_OTLP_EXPORTER_ENDPOINT` to the Alloy URL.
## Motivation Code examination revealed that there are some inefficiencies in the handling of the contract code: * The metering is applied even when the application is already in the cache. Clear loss. * The code is serialized and then deserialized when constructing an instance. ## Proposal Put the metering inside of the construction of entries in the cache. That part is clear. Then simplify the construction of the engine. ## Test Plan CI. ## Release Plan Can be potentially released in `testnet_conway`. ## Links None
## Motivation More clippy corrections that should be catch are added to `Cargo.toml`. Fixes #5573 ## Proposal Do it in a very straightforward way. ## Test Plan CI ## Release Plan We could be added to `testnet_conway`. ## Links None
## Motivation `test_evm_erc20_shared` sends 500 EVM operations in a single request. On CI this can exceed the 30-second HTTP timeout, causing a retry that fails with a block conflict because the first request actually succeeded server-side. ## Proposal Increase the timeout. ## Test Plan CI: Let's see if it's still flaky. ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Motivation There is a check of outcome returns that in one branch decays to checking that `outcome == outcome.clone()`. This is not needed. ## Proposal Restructure the test to avoid that scenario. ## Test Plan CI. ## Release Plan Could be backported to `testnet_conway`. ## Links None.
## Motivation
We'd like to be able to fall back to trying another wallet if the wallet
is not available. While this is technically possible with the lock
happening in `new Client`, it is rather cumbersome to have to create the
whole client before we find out whether we need to fall back.
## Proposal
Try to lock early, in `Faucet.claimChain`, and error on failure. If no
chain is claimed, the default wallet is still locked when we construct
the client.
## Test Plan
Playwright test added.
## Release Plan
- These changes should be backported to the latest `testnet` branch,
then
- be released in a new SDK,
## Links
- [reviewer
checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
---------
Signed-off-by: James Kay <james.kay@linera.io>
## Motivation This test had some problems of duplicated notifications. A possible origin of this class of error is the function `compute` which is a CAS function and so can be used several times if a notification A is sent at the same as notification B, the function can be called several times. This is why the manual [papaya](https://docs.rs/papaya/latest/papaya/struct.HashMap.html#method.compute) recommends using a function that is pure. The function that we used and was emitting notifications is definitely not pure, nor idempotent. On the other hand, duplicate notifications, do not have to be fatal to the running of an application. ## Proposal We address the purity of the function by changing the code and emitting the notification out of the `compute` code. We also make the CI test resistant to duplicate notifications. ## Test Plan CI. The test `test_end_to_end_repeated_transfer` is reintroduced. ## Release Plan The change could be backported to `testnet_conway`. ## Links None
## Motivation The `inbox` entry is accessed many times ## Proposal We access the mutable inbox and then drop it after use. Also remove useless code. ## Test Plan CI ## Release Plan Could be backported to `testnet_conway`. ## Links None.
## Motivation Linera currently has no way to bridge assets or state between its microchain ecosystem and EVM-compatible chains. Users who hold tokens on Ethereum (or other EVM chains) cannot move them onto Linera, and vice versa. This PR lands the complete Linera↔EVM bridge infrastructure that was developed on the `bridge-main` feature branch. ## Proposal This is a merge of the `bridge-main` feature branch (38 commits) into `main`, introducing the **Linera↔EVM bridge** — a cross-chain bridging system with on-chain verification of Linera state on EVM chains. ### New crate: `linera-bridge` - **Solidity contracts**: `LightClient.sol` (Linera committee/epoch tracking on EVM), `Microchain.sol` (microchain state verification), `FungibleBridge.sol` (lock/unlock ERC-20 tokens against Linera proofs), `BridgeTypes.sol` / `WrappedFungibleTypes.sol` (auto-generated ABI types) - **Proof generation** (`src/proof/`): Merkle proof construction and serialization for verifying Linera certificate data on-chain - **EVM client** (`src/evm/`): Light client management, microchain state queries, and contract interaction via `alloy` - **Fungible bridge** (`src/fungible_bridge.rs`): Orchestrates cross-chain token transfers (deposit proofs, ERC-20 lock/unlock) - **Relayer** (`src/relay.rs`, `src/main.rs`): Long-running service that watches for Linera events and submits them to EVM contracts, with logging and retry logic - **Gas management** (`src/gas.rs`) - **Test infrastructure**: Unit tests, Anvil-based integration tests, snapshot/format tests, and a separate `tests/e2e/` subcrate for Docker-based end-to-end tests (committee rotation, fungible bridging, EVM→Linera deposits) ### New example applications - **`evm-bridge`**: Linera WASM application that processes cross-chain deposit proofs from EVM and triggers token operations - **`wrapped-fungible`**: Fungible token variant with `Mint`/`Burn` operations, used as the Linera-side backing token for bridged EVM assets - **`bridge-demo`**: Web UI (Vite + vanilla JS) with setup scripts for running a local bridge demo end-to-end ### CI/CD & Docker - New `bridge-e2e.yml` GitHub Actions workflow with try-pull/build-if-missing pattern for Docker images - `Dockerfile.bridge` and `Dockerfile.foundry` for bridge and Solidity toolchain images - `docker-compose.bridge-test.yml` for local e2e test orchestration - `docker/build-bridge-image.yaml` Cloud Build config - GCP Workload Identity Federation for CI auth - Bridge-main added to `docker_image.yml` and `rust.yml` CI branch filters ### Supporting changes across the monorepo - **`linera-base`**: Added `BcsHexBytes` wrapper and `AccountOwner::address_bytes()` for EVM address derivation - **`linera-chain`**: Exposed `block_header` field on `ConfirmedBlock` - **`linera-client`**: Extended `ClientContext` with helper methods for bridge wallet/storage initialization - **`linera-service`**: New `evm_chain_exporter` runloop in the exporter service (exports Linera committee changes to EVM); `WalletState` config extensions - **`linera-faucet`**: Exposed `open_chain_with_initial_balance` for bridge setup flows - **`linera-execution`**: Minor EVM database fix (`EvmState::default()` instead of `HashMap::new()`) - **`Cargo.toml`**: Added `linera-bridge` to workspace, pinned `alloy` to `=1.0.42`, added `alloy-rlp` and `alloy-trie` dependencies ## Test Plan - **Unit tests**: `cargo test -p linera-bridge` — proof generation, BCS serialization, format snapshot tests - **Integration tests** (require Anvil + solc): `cargo test -p linera-bridge -- --ignored` — Solidity contract deployment, on-chain proof verification, deposit proof flow - **E2E tests** (Docker): `linera-bridge/tests/e2e/` — full end-to-end committee rotation relaying, Linera→EVM fungible bridging, EVM→Linera deposit flow using containerized Linera validators + Anvil - **Example app tests**: `cargo test -p evm-bridge`, `cargo test -p wrapped-fungible` - **CI**: `bridge-e2e.yml` workflow runs Docker-based e2e tests; `rust.yml` builds the `evm-bridge` WASM app ## Release Plan - Nothing to do / These changes follow the usual release cycle. ## Links - Individual PRs merged into `bridge-main`: #5456, #5493, #5495, #5498, #5499, #5500, #5504, #5505, #5540, #5582, #5583, #5585, #5590, #5592, #5605, #5607, #5623, #5628 - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist)
## Motivation The test `test_wasm_end_to_end_social_event_streams` is regularly failing in CI. We propose here a solution to the problem. Fixes #5761 ## Proposal In the test, `app1` emits a post that should be received by `app1`. Just after that, a transfer is being done. The call to `app1` leads to the creation of a stream entry to chain2. But the transfer also leads to another message. I do not think we have guarantees about the order in which the calls are being processed. Therefore, we can have the next block that has the transfers and the one after that the new post. Or the reverse. So, the test has to be changed. ## Test Plan CI is the goal. ## Release Plan Can be backported to `testnet_conway`. ## Links None
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Proposal
Test Plan
Release Plan
devnetbranch, thentestnetbranch, thendevnetand release a newSDK soon.
Links