Demo Data from EDBT 2026 / reviewers in the wild / expert
Siva Maradana
dblp:357/9947
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2023
0009-0008-5279-5227ORCID · reported
Domains — the database's venue-derived domains; a paper can count in several
Security and privacy · 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.
| Network and information security
1 paper |
Cryptographic primitives and cryptanalysis · 50% Blockchain and cryptocurrency security · 50% |
Topics — the 1 heaviest of 2, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Cryptographic primitives and cryptanalysis › pseudorandom functions
verifiable random functions |
0.7 | 1 | 2023 | FlexiRand: Output Private (Distributed) VRFs and Application to Blockchains · CCS 2023 |
Methods — techniques the papers use, named apart from their topics
smart contract · 0.7distributed VRF · 0.7
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2023 | FlexiRand: Output Private (Distributed) VRFs and Application to BlockchainsabstractWeb3 applications based on blockchains regularly need access to randomness that is unbiased, unpredictable, and publicly verifiable. For Web3 gaming applications, this becomes a crucial selling point to attract more users by providing credibility to the "random reward" distribution feature. A verifiable random function (VRF) protocol satisfies these requirements naturally, and there is a tremendous rise in the use of VRF services. As most blockchains cannot maintain the secret keys required for VRFs, Web3 applications interact with external VRF services via a smart contract where a VRF output is exchanged for a fee. While this smart contract-based plain-text exchange offers the much-needed public verifiability immediately, it severely limits the way the requester can employ the VRF service: the requests cannot be made in advance, and the output cannot be reused. This introduces significant latency and monetary overhead. Aniket Kate, Easwar Vivek Mangipudi, Siva Maradana, Pratyay Mukherjee |
CCS | 3 |