Terms¶
- Store¶
A Store is operated by a merchant to sell (physical) goods. It exists an EIP721 as on-chain information in our Smart Contract system. It is mainly accessed by a JavaScript-powered Website, available at a certain known domain, which interacts with a Relay to supply the Listing.
- Relay¶
A Relay main job is to manage the Listing and Inventory of a Store. It is also responsible to sequence Event writes from Users into a logical log of Events and send Events to all Clients of a Store.
- KeyCard¶
A seperate cryptographic KeyPair that is used to primarily for interacting with the Relay. It is used to sign Event’s and transactions, and is used to identify the User to the Relay. Its main purpose is to reduce interactions with the Wallet of a User. See KeyCards vs User Wallets for more information.
- Listing¶
Contains the public information of Items in a Store. Names, Prices and other metadata.
- Inventory¶
Is private to the Store. It is information attached to Items. Most notably how many of an Item are available at a given time, since this could be used to profile sales if it were public.
- Wallet¶
A Wallet is a piece of software that is used to manage a User’s funds, creation of cryptographic signatures and interaction with Smart Contract’s. A common example is MetaMask.
- Smart Contract¶
A Smart Contract is a piece of code that is executed and verified by VM Blockchain, like Ethereum. The Mass Market system consists of three Smart Contracts: Store Registry, Relay Registry, and Payments Factory. See Smart Contracts for more information.
- Operator¶
The Operator of the Relay is responsible for funding the Wallet of the Relay, so that it can pay for the needed Gas. - While Store owners can host their own Relay’s, they shouldn’t have to. The long-term idea being that we find ways to incentivising the operation of Relay’s that serve multiple Store’s. Those people being the Operators.
- Eventual Consistency¶
In contrast to classical on-line database systems (e.g. RDBMS like SQL), in event sourcing (ES) (aka append-only logs) all mutations of the state are broken up into discrete events. Hence, instead of retrieving a full table of data, each INSERT and DELETE is transmitted individually, at least conceptually. This helps a lot in distributed systems to gain eventual consistency, which allows for fault tolerant processing during network partitions, if the required semantics can be established for partitioned scenarios.