ODYSSEY: Reestablishing Confidentiality in Confidential Blockchain via Delegated Execution
This paper introduces ODYSSEY, a confidential blockchain system that mitigates execution-inference and execution-replay attacks in Trusted Execution Environments through a novel delegation model and optimized techniques, achieving high throughput and low latency on the FISCO BCOS platform.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a high-stakes poker game being played by a group of business partners. They want to keep their cards and betting strategies secret from each other, but they also need to trust that the game is being played fairly and that no one is cheating by looking at the cards or rewinding time to change a bet.
This is the problem ODYSSEY solves for "Confidential Blockchains."
Here is a simple breakdown of the paper's story, using everyday analogies.
The Problem: The Glass House and the Time Machine
The paper starts by explaining that current "Confidential Blockchains" (blockchains where data is hidden) are built inside special, secure computer chips called TEEs (Trusted Execution Environments). Think of a TEE as a glass house.
The Glass House Leak (Execution-Inference Attack):
Even though the glass house protects the contents, a spy outside can still peek through the windows. They can't see the cards directly, but they can watch how the players move.- The Analogy: If a player suddenly stands up and paces back and forth every time they get a good hand, the spy learns the strategy without ever seeing the cards. In the paper, hackers watch the computer's "pacing" (memory usage and CPU heat) to guess what secret data is being processed.
- The Result: The game becomes unfair because the spy knows more than the players.
The Time Machine Leak (Execution-Replay Attack):
The glass house doesn't have a "Save Game" button that prevents rewinding.- The Analogy: A cheater plays a hand, sees the result, and if they don't like it, they hit "Rewind" to go back to the start, try a different move, and see the result again. They keep rewinding until they find the perfect move that guarantees a win.
- The Result: The game is rigged because the cheater can try every possible outcome until they find the one that works best.
The Solution: ODYSSEY
The authors built a new system called ODYSSEY to fix these two leaks. They didn't try to make the glass house opaque (which is hard and slow); instead, they changed who plays the game.
1. The "Trusted Delegate" Strategy (Fixing the Glass House)
Instead of every player watching every other player's moves, the system uses Delegated Execution.
- The Analogy: Imagine you have a trusted friend (a "Delegate"). You hand your cards to your friend, and only your friend looks at them and makes the move. The other players at the table don't see the cards or watch your friend's hands; they only see the final result (e.g., "Bet $100").
- How it works: You pick a specific node (computer) you trust to handle your secret transaction. That node does the work inside its secure chip. The other nodes just wait for the result. Since the other nodes never see the secret data or the process, the "spy" can't learn anything by watching the process.
2. The "Order-First" Rule (Fixing the Time Machine)
To stop the rewinding, ODYSSEY uses an Order-Then-Execute architecture.
- The Analogy: In a normal game, you might try a move, see what happens, and then decide if you want to keep it. In ODYSSEY, the referee writes down the order of moves first and locks it in a book. Once the order is locked, the players must execute the moves exactly as written. You cannot go back and change the order or try a different move.
- How it works: The system agrees on the list of transactions before anyone starts processing them. Once the list is locked, no one can "rewind" the computer to try a different outcome. The result is final.
The Speed Bumps and How ODYSSEY Jumps Them
The authors admit that having a "Trusted Delegate" creates a new problem: Traffic Jams. If everyone sends their cards to one friend, that friend gets overwhelmed, and the game slows down. Also, what if that friend refuses to play (a "Denial of Delegation" attack)?
ODYSSEY adds two clever features to keep the game fast and running:
Location-Aware Concurrent Execution (The Traffic Cop):
- The Analogy: Instead of one person doing all the work, the system splits the deck of cards into smaller piles. It assigns different piles to different trusted friends based on who is closest or what cards they need. It's like a kitchen where the chef doesn't chop all the vegetables alone; they assign the onions to one person and the carrots to another, but they make sure the onions are chopped before the soup is made if the recipe requires it.
- The Result: Many things happen at the same time without messing up the order, keeping the system fast.
The Delegation Failure Handler (The Backup Plan):
- The Analogy: If your trusted friend suddenly falls asleep or refuses to play, the game shouldn't stop forever. ODYSSEY has a timer. If the friend doesn't make a move quickly enough, the system automatically says, "Okay, we'll skip this move for now and move to the next one," so the game keeps going.
- The Result: The system stays alive even if some participants are lazy or malicious.
The Results: Did it Work?
The team built a working prototype of ODYSSEY using a real blockchain platform called FISCO BCOS. They tested it in two environments: a fast local network (LAN) and a slower, wide-area network (WAN), like the internet.
- The Verdict: ODYSSEY is slightly slower than a standard, non-secret blockchain (because security always costs a little speed), but it is very fast for a secret system.
- The Numbers: In a wide-area network with 3 nodes, ODYSSEY could handle about 4,000 transactions per second with a delay of only 0.4 to 0.5 seconds.
Summary
ODYSSEY is a new way to run secret blockchains. Instead of trying to make the "glass house" invisible (which is hard), it limits who gets to look inside by using trusted delegates. It also locks the order of events so no one can rewind time to cheat. It solves the security leaks of current systems while keeping the speed high enough for real-world business use.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.