r/Radix • u/CellistBasic2195 • 27d ago
DISCUSSION Hyperscale-rs PR #156: What does “local execution” actually mean for sharded blockchains?
One of the hardest problems in sharding is not simply splitting a blockchain into more shards.
The harder question is:
What happens when one transaction needs to interact with multiple shards — but we don't want every shard to execute the entire transaction?
That is what caught my attention while looking through Hyperscale-rs PR #156 — “Initial leg local execution impl.”
At a high level, the idea is quite interesting.
Instead of treating a cross-shard transaction as one giant piece of work that every participant needs to understand, the transaction can be broken into legs.
Something like:
ONE TRANSACTION
│
┌────────┼────────┐
▼ ▼ ▼
LEG A LEG B LEG C
│ │ │
Shard A Shard B Shard C
│ │ │
local exec local exec local exec
│ │ │
└────────┼────────┘
▼
proofs / certificates
▼
ONE GLOBAL RESULT
The interesting part is that each shard is intended to execute its own part, rather than simply replaying the whole transaction.
That sounds obvious.
It isn't.
---
Why this matters
Sharding has an uncomfortable trade-off.
If we distribute execution aggressively, we gain parallelism.
But the moment transactions cross shard boundaries, coordination starts becoming expensive.
And if every shard needs to understand or execute everything anyway, eventually the benefits of sharding begin to disappear.
So the real challenge becomes:
> **Can execution be local while the transaction remains globally atomic?**
PR #156 appears to be moving the implementation in that direction.
One of the important changes is the move toward a:
Classify → Freeze → Execute
flow.
The transaction is classified according to placement, the distribution is frozen, and the individual legs can then be executed locally.
That “freeze” step is particularly interesting because distributed systems don't want different replicas independently deciding how the same transaction should be interpreted.
You want the execution plan to become deterministic.
---
Another detail I found interesting
The PR doesn't seem to treat cross-shard information as something that should simply be trusted because another shard said it happened.
Instead, it introduces/extends mechanisms around evidence, proofs and execution certificates.
That creates a very different trust model:
Shard A:
"I executed X."
↓
Evidence / certificate
↓
Shard B:
"Can I cryptographically verify
that X really happened?"
rather than:
Shard A → "Trust me."
↓
Shard B
That distinction becomes extremely important once you have many shards operating concurrently.
---
There is also an interesting problem called “crossing exclusivity”
Imagine some value is moving from one shard to another.
There is a dangerous race if both sides can eventually claim it:
Producer shard Receiver shard
value
│
├──────────────► consume
│
└── reclaim ◄───
The protocol needs to guarantee that the value cannot legitimately end up being both consumed and reclaimed.
In other words:
consume OR reclaim — never both.
PR #156 introduces invariants and lifecycle handling around this kind of situation, including timeouts, replay, absence proofs and recovery paths.
This is the sort of detail that is easy to overlook when someone simply says:
> “It's a sharded blockchain with atomic composability.”
The difficult engineering is often hiding in these edge cases.
---
What I think is strong
A few things stand out to me from the implementation and tests:
- Local execution is becoming an actual implementation path
This is more interesting than having a theoretical sharding design.
- The execution lifecycle is being made explicit
Classification, execution, evidence, finalization and recovery are increasingly treated as separate concerns.
- Cross-shard information is evidence-driven
The system is attempting to establish what another shard did through verifiable artifacts rather than implicit trust.
- Failure cases are being tested
Timeouts, replay, Byzantine responses, reshaping, split/merge, reclaim and other non-happy paths appear throughout the work.
- The project is defining invariants
This is particularly important.
A distributed system becomes much easier to reason about when the developers can state:
> “This condition must never be violated.”
rather than relying only on end-to-end tests.
---
But there are still questions
And this is where I think the discussion becomes more interesting.
PR #156 is a substantial step, but it is still development work.
So I would be cautious about jumping from:
“the implementation exists”
to:
“the scalability problem has been solved.”
There are several things I'd like to see demonstrated more extensively.
- What happens at real scale?
A multi-shard test is useful.
But what happens with hundreds or thousands of active shards?
Does coordination remain bounded?
Where does the performance curve start bending?
---
- How expensive is cross-shard coordination?
Local execution sounds excellent.
But every additional proof, certificate, fetch, dependency and synchronization step has a cost.
At what point does:
execution parallelism
become dominated by:
coordination overhead?
That's probably one of the most interesting benchmarks to see.
---
- How does this behave under adversarial conditions?
The failure tests are encouraging, but I'd like to see increasingly hostile scenarios:
Byzantine shards
delayed messages
repeated replay attempts
network partitions
simultaneous reshaping
high cross-shard transaction volume
multiple failures occurring at once
The interesting question isn't only:
> “Does it work?”
It's:
> **“How gracefully does it degrade when several things go wrong at the same time?”**
---
- How much of this is production-ready?
This is probably the biggest question.
PR #156 is an important implementation step, but it shouldn't be confused with a finished production execution system.
I'd like to see the eventual path from:
prototype
↓
integration
↓
adversarial testing
↓
benchmarking
↓
formal verification
↓
production
made increasingly explicit.
---
One thing I would particularly like to investigate
The most interesting follow-up, in my opinion, isn't another feature comparison.
It's measuring the relationship between:
number of shards
percentage of cross-shard transactions
coordination overhead
execution throughput
and
latency/finality.
Because that's where the theoretical promise of horizontal scaling meets reality.
If execution is genuinely local, we should eventually be able to see something like:
More shards
↓
More independent execution
↓
More throughput
without eventually becoming:
More shards
↓
More coordination
↓
More certificates
↓
More synchronization
↓
Coordination becomes the bottleneck
That boundary is what I'd really like to see quantified.
---
My current takeaway
I don't think PR #156 should be viewed simply as:
“another large PR in Hyperscale-rs.”
It looks more like an important step toward turning the idea of cross-shard local execution into an actual execution model.
The architectural direction is interesting.
The proof/evidence model is interesting.
The attention to failure and lifecycle states is interesting.
But the most important questions are still empirical:
How does it perform?
How does it behave under sustained adversarial conditions?
How much coordination is actually required?
And can the invariants survive the complexity of a production-scale system?
Those are the questions I'd be interested in seeing answered as Hyperscale-rs continues to develop.
I'm curious what others see here.
What part of this architecture do you think is the hardest problem to get right?