Demo Data from VLDB 2026 / reviewers in the wild / expert
Dominic Williams 0003
dblp:175/8182-3
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2022
—ORCID · unresolved
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Distributed systems · 100% |
Topics — the 5 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Distributed systems › group communication
atomic broadcast |
0.6 | 1 | 2022 | Internet Computer Consensus · PODC 2022 |
Distributed systems › consensus
byzantine agreement |
0.6 | 1 | 2022 | Internet Computer Consensus · PODC 2022 |
Distributed systems
consensus |
0.6 | 1 | 2022 | Internet Computer Consensus · PODC 2022 |
Distributed systems › consensus
leader-based consensus |
0.6 | 1 | 2022 | Internet Computer Consensus · PODC 2022 |
Distributed systems › fault tolerance › fault-tolerant protocols
reliable broadcast |
0.6 | 1 | 2022 | Internet Computer Consensus · PODC 2022 |
Methods — techniques the papers use, named apart from their topics
partial synchrony · 0.6gossip sub-layer · 0.6blockchain integration · 0.6
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2022 | Internet Computer ConsensusabstractWe present the Internet Computer Consensus (ICC) family of protocols for atomic broadcast (a.k.a., consensus), which underpin the Byzantine fault-tolerant replicated state machines of the Internet Computer. The ICC protocols are leader-based protocols that assume partial synchrony, and that are fully integrated with a blockchain. The leader changes probabilistically in every round. These protocols are simple and robust: in any round where the leader is corrupt (which itself happens with probability less than 1/3) or the network is asynchronous, each ICC protocol will effectively allow other parties to step in and propose blocks for that round and to move the protocol forward to the next round. In case there was no agreement on a single block in a round, a decision for this round will be taken in a later round with synchronous network behavior and an honest leader. The task of reliably disseminating the blocks to all parties is an integral part the protocol. We present three different protocols, along with various minor variations on each. The first of these protocols (ICC0) illustrates the combination of the main building blocks in a simplified manner for an easier presentation and analysis. Protocol ICC1 is designed to be integrated with a peer-to-peer gossip sub-layer, which reduces the bottleneck created at the leader for disseminating large blocks, a problem that all leader-based protocols must address. Our Protocol ICC2 addresses the same problem by substituting a lowcommunication reliable broadcast subprotocol (which may be of independent interest) for the gossip sub-layer. Jan Camenisch, Manu Drijvers, Timo Hanke, Yvonne-Anne Pignolet, Victor Shoup, Dominic Williams 0003 |
PODC | 6 |