Liran Funaro

dblp:182/6309 · DBLP profile ↗
← Back
5ranked-venue papers
3as first author
2since 2021 · last 2025
0000-0003-3959-1680ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 3 · 3 first-authorSecurity and privacy · 2 · 2 since 2021Software engineering, systems software and programming languages · 2 · 2 since 2021
YearPublicationVenuePosition
2025 Censorship by Procrastination Attack in Leader-Based BFT Blockchains
Raïssa Nataf, Liran Funaro, Hagar Meir, Dany Moshkovich, Yoav Tock
ICBC2
2023 Orion: A Centralized Blockchain Database with Multi-Party Data Access Control
abstract
Blockchain databases were designed to improve trust in centralized ecosystems, which dominate the market today, by introducing tamper-evidence features on top of a classical database. Compared to decentralized ledger technologies, blockchain databases are easier to use, and they can significantly reduce the operational and development costs. However, the existing blockchain databases do not equip multiple parties with tools to efficiently control common data written to the ledger. This paper describes Orion, a new open source blockchain database that introduces multi-sig and proof capabilities with extensive key-level access control, which enable parties to mutually control and validate a value written to the database. These unique capabilities, together with additional blockchain properties, provide users with features such as tamper-evidence, provenance, data lineage, authenticity, and non-repudiation, while using a standard data model and transactional APIs. We found our technology to be extremely useful in improving the integrity of a system and reducing mistakes, disputes, and fraud.
Artem Barger, Liran Funaro, Gennady Laventman, Hagar Meir, Dany Moshkovich, Senthilnathan Natarajan, Yoav Tock
ICBC2
2020 Memory Elasticity Benchmark
abstract
Cloud computing handles a vast share of the world's computing, but it is not as efficient as it could be due to its lack of support for memory elasticity. An environment that supports memory elasticity can dynamically change the size of the application's memory while it's running, thereby optimizing the entire system's use of memory. However, this means at least some of the applications must be memory-elastic. A memory elastic application can deal with memory size changes enforced on it, making the most out of all of the memory it has available at any one time. The performance of an ideal memory-elastic application would not be hindered by frequent memory changes. Instead, it would depend on global values, such as the sum of memory it receives over time.
Liran Funaro, Orna Agmon Ben-Yehuda, Assaf Schuster
SYSTOR1
2019 Stochastic resource allocation
abstract
Suboptimal resource utilization among public and private cloud providers prevents them from maximizing their economic potential. Long-term allocated resources are often idle when they might have been subleased for a short period. Alternatively, arbitrary resource overcommitment may lead to unpredictable client performance.
Liran Funaro, Orna Agmon Ben-Yehuda, Assaf Schuster
VEE1
2016 Ginseng: Market-Driven LLC Allocation
Liran Funaro, Orna Agmon Ben-Yehuda, Assaf Schuster
USENIX ATC1