//STORE enables these computing, economic, and governance primitives

Zero-fee settlement-layer enables

Zero-fee, peer-to-peer value transfer

Fast transactions

Scalable transactions

Democratic and 2/3 censorship resistant governance (one entity, one vote)

Tokenized Data enables

Data to be open and tradable

Data to be programmable by third party apps and devices

Data to have a monetary premium (like $STORE, $BTC, $ETH, $EOS, and gold)

Datacoin revenue to be shared with users, citizens, more

…which enables these high-level use cases

Zero-fee settlement-layer enabled

Tokenized data enabled (p2p cloud)

High-level Use Cases

Fast, zero-fee, programmable payments for the public internet

Voting on the global rules of a decentralized, zero-fee digital asset

Zero-fee, 2/3 censorship resistant value transfer of data as a digital asset

Voting on the global rules of decentralized, open, and programmable data

A web2 app developer opening APIs for other developers to build with (for $STORE)

An IoT device developer live streaming datasets for anyone to access (for $STORE)

A health care system making a prized and rare dataset available (for $STORE)

An autonomous car or drone opening its ML-ready, live data streams (for $STORE)

A local government streaming IoT device data for anyone to access (for $STORE)

(If we publish, we’ll award you with 100,000 $STORE – enough to compete in founding mining auctions.)

While STORE transactions are zero-fee for both end users and developers, if STORE is initially deployed as n ERC20 token on Ethereum, applicable gas fees apply on Ethereum. All settlement transactions on Ethereum incur gas fees. When the ERC20 STORE tokens are swapped with native STORE token tokens, transactions will be settled on the STORE network and at that time, zero-fee transactions are resumed.

April 29, 2019 . 5 min read

STORE Q1 Engineering Updates

Q1 2019 was extremely productive for STORE on the engineering front. Here are a few of the key highlight activities.

Blockchain Simulation to prove correctness in the presence of adversaries

The simulation was designed to demonstrate messagenodes coming to leaderless agreement on the same set of transactions for the same block. The simulation incorporated adversaries who exhibit malicious behaviors such as dropping (not delivering) messages, delaying messages arbitrarily, and corrupting messages during consensus rounds. Importantly, we demonstrated that honest nodes reach agreement even in the presence of these malicious actors. Finally, the simulation modeled network latency by introducing arbitrary delays for every message delivered in consensus rounds; a demonstration of the asynchronous nature of the underlying communication channel. Together, these simulations were captured in a video demonstrating the correctness of the core consensus algorithm. In Q2, we will extend this simulation to demonstration the behavior of validators, showcasing end-to-end block construction and validation flow. Additionally, we will incorporate secure communications through encrypted p2p channels between the nodes, as well as incorporate signature schemes demonstrating how nodes authenticate each other before accepting messages from peers.

Developed proof-of-concept for secure p2p communication between nodes

We prototyped encrypted messaging between peers using the Noise protocol. Additionally, we prototyped peer discover so that messagenodes and validators can find peers and connect to them securely. In Q2, we’ll be integrating these concepts into the BlockFin simulation.

Created the spec for the STORE address format

We developed the first specification for the wallet address format for STORE transactions, with our address following Bitcoin’s address format with some minor changes.

Created the spec for how Rate limiting and DDoS prevention works in STORE

The STORE blockchain consists of a two-tier network of Validators and Messagenodes, each of which is vulnerable to DDoS. The document argues that DDoS attacks can never be fully avoided and that the strategy must be to leverage multiple strategies to mitigate those types of attacks. We talk about the strengths and weaknesses of various strategies in the STORE context.

Created draft spec for STORE’s database schema

We developed a draft specification for the database schema of the STORE blockchain. A relational database is assumed for strict schema enforcement. Since blockchain is immutable, we use append-only design pattern for database tables also. Almost all the tables in the database are immutable — the records once inserted can never be modified or deleted. The immutability ensures simple design, both at the database and application layers.

Created draft spec for STORE Platform

We’ve started to publicly discuss how we transform STORE from a zero fee p2p payments platform to a truly peer-to-peer compute platform. This spec represents the first draft explaining the technical architecture of that platform.

Thanks for your email address! You'll start receiving updates soon.

Loading...

KYC/AML checks are required for securities law compliance. This will be a Reg D and Reg S global offering.

DISCLAIMER

Nothing herein is intended to be an offer to sell or solicitation of offer to buy, STORE tokens or rights to receive STORE tokens in the future. In the event that STORE conducts an offering of STORE tokens (or rights to receive STORE tokens in the future), STORE will do so in compliance with all applicable laws which may include the Securities Act of 1933 and the rules and regulations promulgated thereunder, as well as applicable state and foreign law. Any offering for sale to US Persons in a regulated transaction will be pursuant to a registration statement qualified by the Securities and Exchange Commission, or an applicable exemption from the registration requirements.