Cardano - Node diversity workshop in Porto - June 2026
This is the full report of the third iteration of the node diversity workshops that took place in Porto on the 2nd & 3rd June 2026. The theme that gathered everyone in the same location was understanding Leios and synchronising together on a set of delivery steps.
The first iteration of the node diversity workshops in Paris on April 25 focused on gathering all known node enthusiasts using Open Space Technology which resulted in starting the dynamic of a decentralised way of contributing
The second iteration in Toulouse on September 25 continued the initial effort and focused on the robustness of testing and more particularly the Antithesis platform capabilities.
A third initative was started in Buenos Aires about scaling with Leios and building a decentralised community of node builders, this Porto workshop continues these discussions and expands it to other themes mentioned in the first two iterations.
If you want to know what’s happening after the event you can check the Cardano node diversity action plan or look into the Cardano node diversity agenda
Introduction
One of the main differentiating factor of Cardano is the high level of scrutiny using a research-first, peer reviewed and decentralised methodology.
With this third iteration of the node diversity workshops we invited every known contributor and critic related to Leios towards delivering on the last blockchain trilemma that Cardano currently does not possess: scalability.
We wanted to keep the same mindset as the previous workshops with a day dedicated to specific topics we need to solve together for Leios and another day kept open for ideas. We learned from what happened in Toulouse that in the second day we need to differentiate “main topics” from “optional topics” and organise ourselves in a more efficient way.
Another feedback from both Paris and Toulouse was the difficulty of keeping up with what’s happening in every team and identifying what are the common topic impacting everyone. We took this into account and allocated Damien as the facilitator for keeping up with the next steps forecasted in every topic mentioned in Porto until the next iteration in October.
Attendees
You will find below a picture of everyone that attended the workshops on the 2nd & 3rd June in Porto:
Here is the exhaustive list of people, their role and a map of the node they contribute to or the team they belong to.
| Name | Notes |
|---|---|
| Alex Sierkov | TurboCardano / C++ node, node implementor |
| Alexey Kuleshevich | Haskell node, node implementor |
| Andre Knispel | Haskell node, formal methods on ledger specifications |
| Arnaud Dewulf | Amaru, infrastructure & node operations |
| Boshko Majdanac | Intersect, hard fork working group |
| Carlos Lopez de Lara | Leios, product manager |
| Damien Czapla | Amaru, product & project manager |
| Eric Torreborre | Amaru, node implementor |
| Javier Sagredo | Haskell node, node implementor |
| Julien Eluard | Amaru, node implementor |
| Kevin Hammond | Security Council |
| Marcin Wójtowicz | Haskell node, node implementor |
| Markus Gufler | Haskell node, SPO |
| Martin Kourim | Haskell node, end-to-end testing |
| Matthias Benkort | Amaru, node implementor |
| Nicolas Frisby | Haskell node, node implementor and leios R&D |
| Paul Clark | Leios, simulation & ‘Red Team’ |
| Paolo Veronelli | Haskell node, node implementor |
| Philipp Kant | Haskell node, CTO |
| Pi Lanningham | Amaru, node implementor and Leios |
| Roland Kuhn | Amaru, node implementor |
| Ryan Williams | Intersect, hard fork working group |
| Sebastian Nagel | Leios & Cardano Blueprint |
| Younus Rashid | Amaru, ethical white hacker |
Here is the list of people that we invited but couldn’t attend, they will be part of the next steps organised after this workshop:
| Name | Notes |
|---|---|
| Chris Gianelloni | Dingo, node implementor |
| Clark Alesna | Razor, node implementor |
| Michele Nuzzi | Gerolamo, node implementer |
| Santiago Carmuega | Dolos, node implementor |
| Satya Ranjan | Yano, node implementor |
As this initiative becomes more decentralised we will make both the people invited in those events and the content of the workshop become as open source as possible to improve efficiency. The next years should harness what has been built from all the sessions to welcome new projects/products/use cases by giving access to the brain power available at these workshops.
The main success criteria for that aspect is that a group of individuals (that is not from a single node implementation) picks up the idea and carries the prospect forward using Cardano’s governance mechanisms
Content
This workshop was organised around understanding how can Cardano scale with the help of Leios. We also focused on the delivery targets all node implementers have to achieve.
The structure of the workshop was straightforward:
- Day 1 in the morning we had the Leios team setting the stage with a global picture of the scope and opening up the questions related to delivery;
- Day 1 in the afternoon we took some time to tackle the questions that were raised from the Leios global overview and identified what we need to achieve collectively to solve them;
- Day 2 we spent the day in an open forum environment on the topics that the people contributing to the workshop wanted to solve.
The only difference from the previous workshops organised is that the recap of all the sessions and the outcomes necessary to move forward will be documented and facilitated by one person.
This strategy is from the lessons learned of both Paris & Toulouse workshops where we had a very valuable time in both workshop but were inefficient in between these occurrences.
You will find all the resulting actions from the two days of workshop in this shared action plan where the drumbeat of each topic will be facilitated in a shared Cardano node diversity agenda by Damien
Day 1: Leios
You can find the presentation that were used during the day here:
Introduction and themes of the two days - Damien
Introduction to Leios and content of Day 1 - Sebastian
We kicked off the day with in a very simple fashion to have a grasp of every expectations regarding these two days of workshop.
Everyone had about a minute to introduce:
- Who they are, what they’re doing for Cardano
- Pinpoint one pragmatic outcome they want of these two days
This gave us a pool of ideas, some specific to Leios some more generic to choose from throughout the two days:
Leios day: Morning
The start of the day was dedicated to getting a better understanding of Leios regarding:
- The current plan for delivering Leios
- The architecture breakdown
- The status of each delivery step
- The links to all the existing documentation
CIP-0164; Project repository; Node-level design document; Threat model; Website; Monthly review meetings; Leios prototype of cardano-node
Main takeaways from this sessions are:
- Leios is an overlay of Praos relies on the same security principles
- Cardano & Leios have the same problem: filling the blocks with activity on chain, having Leios implemented will create more possibilities but we need to generate more usage on Cardano
- Handling the high throughput from Leios is the main roadblock for anyone looking to be compliant with an active version of Leios on mainnet
- Leios roadmap is updated regularly and reported monthly on Github and the Website
Afternoon
The discussions both in the introduction of the day and during the session introduced by Sebastian sparked some interesting questions.
Using a simple voting mechanism with the people in the crowd, the following topics won the ballot:
- What design does the mempool of a Cardano node has to do for Leios ? (asked by Javier Sagredo)
- How can we “safely rollout” Leios on mainnet? (asked by Ryan Williams)
- How much resources can we afford Leios to require? (asked by Nick Frisby)
- How should we participate in Leios?; What can we demo using Leios; What would people want from the Leios team to make it work for everyone? (asked by Pi Lanningham; Sebastian Nagel; Damien Czapla)
Every session held will be summarised in this report using the same methodology:
- What were the main takeaways from the discussion
- What are the outcomes (action plan)
- Who should be part of what comes after
for those who come after…
Basis for a high throughput Mempool
Asked by Javier Sagredo
Main takeaways
- Long story short everything (Ledger, Chain DB, Tx submission, EBStore, Block forging) currently relies on the mempool to work with the throughput Leios demands; this creates a bottleneck at the Mempool level
- Maximum size of data to be included in the Mempool: 12Mb
- Validation of transactions takes from 1µs up to 100µs depending on the content
Outcomes
- Action for Javier: update the Cardano blueprint information to include a protocol level mapping of what’s expected of the mempool performance (transaction submission & a valid sequence of blocks) to comply with Leios
Who’s involved
Javier Sagredo, Eric Torreborre
Optional: Haskell node consensus & ledger team, Leios team
How can we safely rollout Leios, without breakings all ecosystem tools
Asked by Ryan Williams
Main takeaways
- Leios impact analysis on Github is good enough to be used as-is
- Detailed analysis of discussion in slide 8 & 9 of the slides from the node diversity workshop
Outcomes
- Action for Ryan (with hard fork group): draft a testnet definition / policy, see: Github markdown file
Who’s involved
Ryan Williams, Hard fork working group (Intersect)
How much resources can we afford for Leios / What does Leios require? (CPU, RAM, Disk, Network usage)
Asked by Nick Frisby
Main takeaways
- Leios CIP-0164 contains relevant simulations depending on which use case is covered
- Cardano’s developer minimum hardware requirements to operate a stake pool gives also a perspective on the current situation
Outcomes
We can’t as of today give an estimate for the resource requirements or the resources that should be allocated to run linear Leios as it is too dependant on the environment and assumptions where it runs.
Participating in Leios & demo showcase
Asked by Pi Lanningham, Sebastian Nagel, Damien Czapla
Main takeaways
There is currently a testnet environment with a prebuilt node that can run Leios and with some docker images existing to run Leios
See slide 10 in Sebastian’s presentation
The Amaru team has set a target for this year in Q3 and Q4 to explore Leios and implement as early as possible a compatible version of Amaru to go with it.
Outcomes
Pi, Paul and Ryan shared their experience of playing with the current testnet environment.
The best way to synchronise together is linking together the Leios roadmap and the Amaru roadmap into common targets for implementation and testing
- Action for Damien to organise a dedicated session for mapping the impact of Leios on the architecture of Amaru. With the current roadmap plans this will be organised in September/October.
Who’s involved
Sebastian Nagel & Carlos Lopez de Lara; Damien Czapla; Amaru core team; Haskell node team
Evening - Restaurant
After a long demanding day we respected the tradition of going to a restaurant with all the people of the workshop and their entourage to enjoy a French dish in its Portuguese flavour with some “magret de canard on a risotto bed”
Day 2: Open forum for Cardano nodes implementers
As per tradition we wanted to keep the initial idea of the Open Space Technology but with a small twist based on the feedback of the first two workshops held.
The twist is rather simple: pinpoint with a voting mechanism what the majority of the people present want to solve.
We also wanted to have an efficient management of the discussion so we designated a facilitator, timekeeper and note taker for the day.
Day 2 morning
To have a productive day we defined 4 sessions in the day to allocate at least 1 hour for each topic that makes the cut.
Since there was 4 sessions in the day we asked every participant to choose 4 topics that interested them with a preference order.
The first one in each of the vote will be worth more towards making the final count for the sessions that will be held.
The following agenda was set and you can see from all the adjustments made timing wise in this picture that discussions were opiniated.
Cardano network & Cardano node observability
Proposed by Markus Gufler; Boško Majdanac; Younus Rashid
Clarification made at the start of the sessions: we need to define the purpose of observability, take the perspective of an SPO, take the perspective of a node implementer, take the perspective of a DApp owner: what should they look at?
Main takeaways
- Cardano is a public blockchain, so the data should be available unless there is a very heavy security concern
- SPOs should have a Prometheus environment running with alerts based on logs and behavioural information of the node (and identify which response is suited for the type of alert they set)
- Markus and Michael Karg are good entry point for knowledgeable information for projects that want to be involved in observability of the Cardano network
- The very nice to have setup is a “set of explaining diagrams” that showcase the flow of steps involved in participating in the Cardano network; then having a set of traces that are related to those steps and finally setup metrics that can help you understand and monitor your setup activity
- The Amaru team took into account Markus’ perspective on things to observe while producing blocks, you can find the result of the team’s discussion in this Engineering Decision Record that defines a tracing span schema.
Outcomes
There was a specific discussion about exposing the node version in the block header that needs to be resolved using the CIP 180 conversation
No direct action were addressed during this session.
Conformance testing, implementation independent, driven by specifications and data sets
Proposed by Alex Sierkov
This session was structured around a 3 step methodology: Why/What/How
- “Why do we need conformance testing”
- “What can be used to do conformance testing”
- “How can we do conformance testing”
Main takeaways
Why:
- Identify gaps between the protocol and the different implementations
- Define the protocol expected boundaries that should exist in each implementation
- Have stronger specifications, testing and release strategies on Cardano
- Anything compliant with the specifications & the conformance testing makes the network safe
- Make Cardano a safer blockchain if everyone complies with a set of agreed upon “necessary steps for running on the network”
What:
- Serialisation/deserialisation of transaction
- Ledger rules)
- Transaction level invariants (block level)
- Ledger state (canonical)
- Diffusion / networking mini protocols
- Chain selection
- Plutus: execution results of the VM
- Node 2 Client protocols
- Network thresholds / Software Level Agreements / Delta Q
Raised topic: we should have a mapping the business use cases currently on Cardano in the specifications and start creating scenarios to be tested to answer for those business cases.
How:
- Generic approach 1: Build a test environment; Get results; Define and run edge cases; Use on testnets, mainnet and Antithesis
- Generic approach 2: define together data sets + a to do list on a specific test format
- UPLC fuzzer: Cardano Plutus VM benchmarks (Turbo) are a very good example to follow
Outcomes
- Action for Paul: Have an overview of the status of progress of the Canonical ledger state CIP implementation with Tweag team
- Action for Andre: Networking and mini protocol specification overview (with Roland & Eric)
- Action for Damien: organise a bi-monthly call to follow up on the “How” delivery plan
- Action for Damien: define with the people contributing the best way to communicate together, align on the next steps (known sources: Cardano Scaling/Node diversity Discord Cardano blueprint)
Who’s involved
Paul Clark; Andre Knispel; Damien Czapla; all known node implementers lead architect
What does “High confidence” means for deploying Leios
Proposed by: Paul Clark & Carlos Lopez de Lara
This session got inspired by the previous one and was also structured around a 3 step methodology: Why/What/How
- “Why do we need high confidence before deploying Leios”
- “What can be used to get high confidence”
- “How can we get high confidence”
Main takeaways
Why:
- Do no harm to the Cardano network, not breaking anything for people using it
- Give a robust perspective for teams to have a good release candidate for Leios
- Be able to push a release that handles the scale of throughput Leios delivers
- Have a smooth hard fork process
What:
- Structured approach for demonstrating safety; liveness; usefulness
- Robust and successful hard fork process covering the biggest behaviours of the Cardano network Leios modifies
- Have a common understanding with the following teams of metrics and delivery steps:
Stake Pool Operators (SPOs)
Development teams of DApps & nodes
Delegate Representatives (DReps)
Technical Steering Committee (Intersect)
Hard Fork working group (Intersect)
Parameter Committee (Intesrect)
Security Council (Intersect)
Information shared about the current hard fork process: Test it on your own; bring it to the hard fork working group with test results; review through the Technical Steering Committee; submit a hard fork action through Intersect; go live on mainnet
How:
- Having a robust hard fork process with every necessary stakeholder involved
- Have a testing environment where applications run to harness the power of Leios
- Have a set of conformance tests related to key Leios changes (consensus; block diffusion; EB fetching and voting)
- Have a long term running sandbox environment running to test limits, stability, DApps & APIs compatibility
- Have a data set for testing with users of the Cardano network (DApps) and some kind of test suite to simulate Leios
- Have specific test cases for use cases (example cited: Rosetta)
- Have a cluster of contributors run, test and generate performance reports
- Generate an environment to break the edge cases of Leios (RB vs EB edge cases simulations)
- Build robust contingency plans (examples mentioned: have a way to use 25% of stake to disable Leios functionalities / have a config file that people can modify to act on the protocol, not voting, not fetching)
- Have a gradual enablement and rollout plan for Leios
Outcomes
-
Action for Paul: Coordinate the efforts related to the “Red teams” activities and the white hacker from Amaru and the Antithesis teams (include “Red teams” activities)
-
Action for Sebastian & Carlos: Have a clarified timeline for DApps, SPOs and node implementers to synchronise with
Ideas:
Have a bunch of throughput test cases that show the setup can handle it
Share a structured approach and process to go through before the hard fork
Convincing all the stakeholders that the overall value chain of Cardano is ready to move
Have a rollout plan that takes into account gradual deployment
Allow 20seconds a day to “allow people to use the Leios parameters” as an experiment on mainnet
-
Action for the Technical Steering Committee: Have a more detailed hard fork process involving precise steps with expected results and outcomes
-
Action for the Technical Steering Committee: Build a contingency plan that can be triggered if something goes wrong (have 25% of the stake under specific control; use a config file for not fetching/not voting…)
-
Action for Damien: clarify the mandate for Amaru participation in Hard forks
-
Action for the Technical Steering Committee: build a to do list (recommendation) to anticipate a parameter change and what needs to be done (and prepare the Guardrails)
Who’s involved
Paul Clark, Sebastian Nagel, Carlos Lopez de Lara, Technical Steering Committee, Hard fork working group, Damien Czapla
Making the consensus specification “more behavioural”
Proposed by: Roland Kuhn
This was a short session that was organised mostly to discuss the outcome of a discussion that has been held in the workshop.
Main takeaways
Following the discussion on the demands of the protocol towards the consensus and the networking stack of a node, Roland will work with Javier to contribute to Cardano blueprint and include the current understanding of the consensus specifications and the networking specifications.
The discussed categories (protocol level) that should be updated are: consensus specification; networking specification; chain selection specification; but an overall analysis needs to be done in order to grasp all the missing specifications.
The sources of information include: docs.cardano.org / developers.cardano.org; soon to be: how.cardano
Outcomes
- Action for Roland Kuhn & Javier Sagredo: create an issue in the Cardano blueprint repo to showcase the current gaps in the Cardano protocol level specifications
- Action for Nick Frisby: contribute with his current understanding on the topics linked to consensus
- Action for Roland Kuhn & Javier Sagredo: After reviewing the state of things, update the Cardano blueprint to include the specifications and overview they are knowledgeable about
Cardano blueprint: include in the CI an “external website check”
Cardano blueprint: clarify the governance model and who’s got authority on pushing things in the repo
Who’s involved
Roland Kuhn, Javier Sagredo, Nick Frisby, Sebastian Nagel
Node diversity leaderboard
Proposed by: Damien Czapla
This small session was organised to disclose an initiative that will be carried forward by a team contributing to Amaru: Sundae Labs.
You can find in the slides 11 to 14 of the presentation of the event
Main takeaways
The Amaru team will create an environment with a CI workflow that uses data sets and test suites to calculate the performance of the various node implementations.
This will be a similar initiative to the Cardano Plutus VM benchmarks (Turbo) but with a more detailed pool of tests and performances benchmarks.
The current scope of the mission includes:
- Map out the added value areas that the CI should cover
- Build an automated CI that runs at least “Cardano protocol compliance tests”
- Create a web interface to access the leaderboard and make the contribution easy
The current categories that we want covered by this leaderboard:
- Protocol level benchmarks
- Conformance tests
- Adversarial scenario compliance
- Subsystem level benchmarks
Outcomes
-
Action for Sundae Labs: generate a first proof of concept to start this initiative at the end of Q3 2026
-
Action for Damien: facilitate the creation of an open source project environment for people to contribute in October 2026 with edge cases, data sets to be added to the leaderboard
-
Discussions were held about the governance process for this project and merging it inside the Cardano Blueprint once the proof of concept has been useful for node implementers and the Cardano community
Who’s involved
Amaru core team, Sundae Labs, Damien Czapla, Sebastian Nagel
Should we make a certification for products that run on the Cardano blockchain
Proposed by: Paolo Veronelli
There was many discussions towards “what would certify a product to be safe to use on Cardano” and Paolo wanted to showcase the current Antithesis setup and how it could be used in a certification process.
Main takeaways
- We need to have a clarified certification process that uses peer-reviews, high standards and available testing suites to guarantee something is “good enough to be used on the Cardano blockchain”
- There should be a proof on chain that shows that your application/product is safe to use on Cardano mainnet
- Currently Antithesis is a deterministic test suite (some kind of a fancy fuzzer that simulates an end to end version of the Cardano network where you can play with time as a variable) including 8 nodes with 4 different versions that can be “Cardano node” “adversarial” “perturbator”
- Antithesis can be a robust step to include in the certification process if adversarial scenarios are explicit
Outcomes
- Action for Paolo: Build a process for certifying “you are deemed worthy of being a Cardano node and you passed all the required tests and edge cases”
Who’s involved
Paolo Veronelli & the team members of each node implementations involved in extensive testing
State of the art of “How to operate a node”
Proposed by: Arnaud Dewulf
Amaru has a specific scope related to building documentation for SPOs that contains:
- Referencing the current Haskell node best practices and sources of information,
- Building an Amaru specific set of documentation of “how to run an Amaru node”
- Building a sandbox environment to experience the User Experience of an SPO using Amaru
Main takeaways
- We already have a good set of documentation for both the network and Haskell node, mapping that out as a first step would be good
- We need to use a “single source of truth” related to operator documentation, this will be how to cardano
- Including the flavours of implementations in a common documentation is a good way forward in a diversified Cardano blockchain
Outcomes
-
Action for Arnaud: review Developers.cardano.org and identify the gaps in documentation to run smoothly a Cardano node (Haskell version)
-
Action for Arnaud: use DApps developers & SPOs input to build the Amaru documentation
-
Action for Arnaud: Make a node agnostic version of the “recommended steps of operating a node”
Overall consensus during the discussion: this scope should contribute to the public information about how to manage a node by giving different flavours to it
Who’s involved
Arnaud Dewulf, Haskell team, Amaru team, SPOs
Day 2 closing
From our initial target of voting for 4 topics to be solved in the morning we managed to solve 9 with an adjusted voting mechanism, and a swift decision making process. We focused on picking topics with the mindset of “what topic can be solved today with a pragmatic outcome that every node implementer agrees we need to carry forward”. This combined with and a setup of having a dedicated facilitator to close most of the discussions held made us efficient.
Given the performance of the day and the involvement of everyone to contribute we didn’t have a feedback session. This feedback loop will instead be carried over to the facilitation meetings that will be held until the next workshop in October.
Conclusion
This Porto workshop felt productive and incentivised on delivering together the promise related to Leios: make Cardano scale.
The atmosphere was constructive even while going into the depth of the technical challenges in front of us. Divergent opinions were heard and taken into consideration with an open mindset
We now have a shared way forward on the topics addressed and an understanding of each team’s role in resolving.
The Amaru team is glad to be able to organise this year’s workshops and keep the dynamic going until we make it a fully decentralised initiative.
Resources
You can follow the meetings organised in the shared node diversity agenda
You can find the resulting shared action plan that will be our synchronisation environment moving forward
You can keep the discussion going in the Cardano forum with the tag
Node development
If you want to directly reach out to the people involved in the workshops you can go to the Cardano Scaling/Node diversity Discord
If you want to reach out to the Amaru team you can join the PRAGMA/Amaru Discord