In this article, we'll discuss how we achieved a tenfold increase in the processing speed of the tx-indexer by applying four key concepts related to our use of key/value storage: Key/Value stores variabilities The importance of Efficient Data Encoding Secondary Indexes Batch Inserts The Transaction Indexer (tx-indexer) is the primary tool Gno.land uses to index its networks. It is in charge of keeping up with block production, fetching new data, indexing it, and serving it to users while providing filtering and subscription capabilities. The tx-indexer creates versatility and ease of use when using on-chain data, which is one of the key aspects of a fully functioning decentralized application. Understanding Key/Value Store Variability

Introduction Distribyted offers a unique solution to handling large datasets as a torrent client. This platform is designed to revolutionize dataset consumption by overcoming traditional storage limitations, enabling data exploration and utilization regardless of its size. Key Features Abstracted Filesystem Approach At the heart of Distribyted is its novel approach to treating torrent files as filesystems. This allows for a range of options, including FUSE, HTTP, and WebDAV. The design is inherently flexible, making the implementation of additional serving methods straightforward and enhancing the application's adaptability to various use cases. Smart Compression Handling Distribyted stands out from conventional torrent clients with its ability to directly mount certain types of compressed files. This feature is particularly advantageous as it enables users to download only the essential parts of a dataset. This efficiency minimizes bandwidth usage and expedites access to critical data, making it an ideal solution for handling large-scale datasets.

This roadmap is getting all the ideas/concerns from gno roadmap workshop and they ordered by teams/parallelizable sections. All the points inside a section are by priority. VM Simplify VM, fix bugs Improve gnolang UX without blockchain Less panics and more meaninful error messages Logging on the node Support better gas estimations and tweak the costs (x6) VM State storage format: solve issues and specify a format sync GC

While a work in progress, this issue will serve as the center point for tokenomics discussion, design, testing, and implementation on the Gno.land GitHub. Many of these ideas have been further refined and confirmed from earlier issues such as #407 - Original Evaluation DAO Proposal, #503 - Original GoR Governance Proposal (2nd draft in comments), and the overall Game of Realms competition #390 - Game of Realms Overview. Thank you to @adr-sk (Andrew K.) and @dongwon8247 at Onbloc for your early governance and tokenomic contributions. Work is also underway regarding the Gno.land fee equation #649 - Fee Equation, please feel free to discuss with @zivkovicmilos, @thehowl, and me. Overview Gno.land is a L1 chain focused on directly rewarding Contributors for building and expanding the network. Gno.land utilizes the Gno language created by Cosmos Co-Founder Jae Kown and further worked on by the community through the Game of Realms competition. Gno is based on Golang, and will be overseen by New Tendermint moving forward. This document will focus directly on the Gno.land ecosystem, with a separate document in the future covering Gno and New Tendermint. Through Gno.land and its novel consensus mechanism Proof-of-Contribution, Contributors will be rewarded with WORX points due to the Contributor DAO membership tier they earn and maintain. Tiers consist of Tier 7 on the low end to Tier 1 on the high end, each offering an increased WORX reward distributed on a regular time interval and increasing VotingPower per tier. Evaluation DAO, a subset of the larger Contributor DAO will propose and vote on Contributor DAO membership, moving Contributors up or down the Tiers, and eventually will help define exact WORX points per contribution. A user will be automatically added to Contributor DAO as a Tier 7 member by simply having any contribution submission accepted by Evaluation DAO. Tendermint and IBC will be utilized for the node network/infrastructure, with Tendermint2 and IBC2 eventually taking their place. Proof-of-Contribution Summary

List by priority 100 nodes controlled for the same entity connecting to our node, avoiding connections from other legit nodes (eclipse attack). 100 nodes asking to our node to do some work, making our node to go down. 1 node opening many connections to our node, forcing that node to do more work. Open and close really fast connections to a node. TLS handshake DoS. What we want to avoid