Sui Foundation is committed to supporting academics and researchers in pushing the boundaries of what's possible in technology, finance, economics, and more. We invite applications for Sui Academic Research Awards (SARAs) from researchers with proposals aligned to our mission to support the advancement and adoption of technology and web3.
<aside> 📚
New Call for Proposals open! Applications can be submitted here at any time until the deadline of March 7th 11:59pm PST.
</aside>
Each proposal must be led by a Principal Investigator (PI) with a track record of peer-reviewed published academic research in relevant fields.
The PI must hold a position or be affiliated with a recognized academic institution and/or research center that is willing to receive and administer the funds awarded.
Accepted proposals will be granted a fixed award of $25k USD, intended to cover costs related to the research. The host academic institutions must accept the grant on behalf of the PI.
As the Sui network matures the Sui foundation has identified specific research topics that can support the Sui ecosystem. Therefore the SARA program seeks applications for research funding that address one or more of these key challenges. Please indicate as part of your application which research challenge(s) you plan to address.
Parallel or distributed execution & execution scheduling.
Following from the work on Pilotfish, we seek options for how to scale up Sui transaction execution across multiple machines within each validator, while maintaining the abstraction of a single large database of objects that can be operated on.
Parallel sequencing & checkpoint creation.
Key aspects of Sui core today will eventually bottleneck the system, and we seek research on the best options for scaling them up. These include the consensus adaptor that serializes all transactions and performs congestion control; and the checkpoint creation process.
Efficient, low-latency transaction and state dissemination.
Today, validators share Sui checkpoints of the transaction sequence to full nodes, and full nodes after execution share full checkpoints for ingestion pipelines. This process can take a few seconds, while finality for transactions may be achieved in less than a second most of the time. We seek options for how to reduce the dissemination latency of finalized transactions, and their resulting state.
Low-latency verified RPCs and Indexers.
Sui can execute vast numbers of transactions, making the engineering of RPC (Remote Procedure Calls) and indexers a challenge. We seek research on the best scalable architecture for all the read paths of Sui, as well as strategies to maintain longer term state in indexers. We also seek research into how Sui can support a wider range of authenticated RPCs for light clients, or how lighter nodes can only maintain a partial state of the Sui chain that is of interest to them.
DAG consensus & blockchain networking.
Sui does not use a gossip layer between validators, but instead direct push of DAG blocks in consensus, and indirect polling when consensus blocks are missing. Currently this process is not cognisant of network topology or costs. We seek research that improves the networking aspects of Sui consensus and other networked components, both in the push, pull, sync, and checkpoint dissemination phase of the protocols.
Storage architectures for high-throughput blockchain transaction execution.
Sui today uses rocksdb for its storage needs. We seek both improvements in how rocksdb is used, as well as research into better adapted storage engines for the purposes of high-throughput transaction processing. It is likely that such storage solutions may be specialized to either the execution or the rpc roles of nodes.
Efficient and effective deduplication, congestion control and DoS protection.
When there is a transient spike in demand that cannot be satisfied given current limits of Sui, how should the system prioritize what to process and protect itself and some quality of service from being overwhelmed? Currently Sui implements IP based rate controls, a per-shared object congestion control mechanism, and a total gas limit on blocks. How could these be improved to extract most work while protecting the system from spikes?
Increase in Decentralization.
Current Sui network is designed to work best with a few hundreds of validators. Can we increase the number of validators, even if they do not actively participate in the main consensus loop in order to get higher assurance?