dApp Browser
Generally, there are three types of applications on top of the Cosmic Interstellar Public Chain. The first category is financial apps, which provide users with more powerful ways to use their funds to manage and enter into contracts. These include sub-currency, financial derivatives, hedging contracts, savings wallets, wills, and eventually even full-scale employment contracts in certain categories. The second category is semi-financial applications, involving money, but there are also substantial non-monetary aspects of the work being done. A perfect example is self-enforcing bounties for solving computational problems. Finally, some applications, such as online voting and decentralized governance, are simply not financially capable.
5.1 Token System
Token systems on blockchains have many applications, from sub-currency representing assets like USDor gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, or even having no connection to traditional values at all The token system can have a role. The token system is very easy to implement in the Cosmic Interstellar Public Chain. The key point to understand is that a currency or token system m is basically a database with one operation: subtract X units from A and give B to X units, provided that (1) A has at least X units before the transaction unit, and (2) the transaction has been approved by A. All that is required to implement a token system is to implement this logic into a contract.
The basic code to implement the token system in Serpent is as follows:
def send(to, value): if self.storage[msg.sender] >= value: self.storage[msg.sender] = self.storage[msg.sender] - value self.storage[to] = self.storage[to] + value
This is essentially a literal implementation of the "banking system" state transition function described further above in this article. First, a few extra lines of code would need to be added to provide the initial steps for distributing currency units, as well as some other corner cases, and ideally, a function would be added to allow other contracts to query the address's balance. But that's all. In theory, a token system based on the Cosmic Interstellar Public Chain could act as a subcurrency, possibly with another important feature that an on-chain Bitcoin-based metacurrency lacks: the ability to pay transaction fees directly in that currency. The way this is implemented is that the contract will maintain a coin balance with which it can refund the coin used to pay the sender, and it will replenish that balance by taking the internal currency unit collected and reselling it. Ongoing auctions. Therefore, users will need to "activate" their accounts with coins, but once they have coins they can be reused because the contract returns them each time.
5.2 Financial Derivatives And Stable Value Currencies
Financial derivatives are the most common application of "smart contracts" and one of the easiest to implement in code. The main challenge in implementing financial contracts is that most financial contracts need to reference external price quotes; for example, a highly desirable application would be a smart contract that hedges the Cosmic Interstellar Public Chain (or another cryptocurrency) against the US dollar Volatility, but doing so requires the contract to know the value of CIPC/USD. The easiest way to do this is to design through a "data feed" contract maintained by a specific party (such as Nasdaq), so that party can update the contract as needed, and provide an interface that allows other contracts to send the contract. A message is sent to this contract, and a response is returned providing the price.
Taking this key factor into consideration, the hedging contract would look like this:
1. Wait for Party A to input 1000 coins.
2. Wait for Party B to input 1000 coins.
3. Record the USD value of 1000 coins calculated by querying the data feed contract in storage, say this is $x.
4. After 30 days, either A or B is allowed to "reactivate" the contract to send $x worth of coins (calculated by querying the data feed contract again for the new price) to A and the rest to B.
Such contracts would have enormous potential in crypto commerce. One of the main problems with cryptocurrencies is the fact that they are volatile. While many users and merchants may want the security and convenience of dealing with crypto assets, they may not want to face the prospect of losing 23% of the value of their funds in one day. By far the most common solution is issuer-backed assets. The idea is that issuers create a sub-currency that they have the power to issue and withdraw units of, and provide a unit of currency to anyone who provides (o ine) a unit of a specified underlying asset (e.g. gold) to them. The issuer then promises to provide one unit of the underlying asset to everyone who backs one unit of the cryptoasset. This mechanism allows all non-crypto assets to be "promoted" into crypto assets, provided that the issuer can be trusted.
In practice, however, issuers are not always trustworthy, and in some cases banking infrastructure is too weak or too hostile to provide such services. Financial derivatives o er another option. Here, a decentralized market of speculators, rather than funded by a single issuer to back an asset, plays the role by betting that the price of a crypto-reference asset, such as CIPC, will rise. Unlike issuers, speculators have no reason to choose to default because the hedging contract places their funds in the hands of custodians. Note that this approach is not fully decentralized, as a trusted source is still needed to provide price quotes, although arguably this is still a huge step forward even in terms of reducing infrastructure requirements (unlike being an issuer, issuing Price feeds do not require a license and may be classified as free speech) and reduce the potential for fraud.
5.3 Identity and Reputation Systems
The earliest alternative cryptocurrency, Namecoin, attempted to use B-itcoin-like blockchains to provide a name registration system where users could register their names in a public database along with other data. The main use case cited is for DNS systems, mapping domain names (such as "bitcoin.org" (or "bitcoin.bit" in the case of Namecoin)) to IP addresses. Other use cases include email authentication and possibly more advanced reputation systems. Here is the basic contract that provides a Namecoin-like name registration system on the Cosmic Interstellar Public Chain: def register(name, value): if !self.storage[name]: self.storage[name] = value
The contract is simple,it's just a database inside the Cosmic Interstellar Public Chain network to which it can be added, but not modified or removed from it. Anyone can register a name with some value, and that registration will remain forever. More complex name registration contracts will also have a "feature clause" that allows other contracts to query it, as well as a mechanism for the name "owner" (ie the first registrant) to change data or transfer ownership. You can even add reputation and trust web features on top of it.
5.4 Decentralized File Storage
The goal of IPFS is to surpass or even replace HTTP, connect all devices in the network through a file system, and build a faster, more secure, and open sharing Internet.
The CIPC team believes that the low-cost and high-speed IPFS storage solution must be the necessary infrastructure for the future decentralized application network. The IPFS network combines decentralization and cost. In digital life, privacy is becoming more and more important, and decentralized storage will surely become a necessity for people in the future. iCloud was once exploited by hackers to leak nude photos of more than 50 Hollywood actresses. This is not an isolated case, as long as the storage of the Internet remains centralized, such things will continue to happen.
CIPC has built-in LibP2P protocol module. LibP2P is used as the network layer for IPFS. A node using LibP2P to communicate with another node can use a variety of di erent transports, including connection delays, and communicate over di erent protocols, negotiating as needed.
The LibP2P module is mainly responsible for the data transfer function in IPFS, that is, routing, network, exchange, etc. DCE takes protecting the privacy and security of user data as its mission, and will provide sustainable, e cient and low-cost storage solutions to DCE users.
An important feature of the protocol is that while it appears that many random nodes can be trusted rather than decide to forget a file, the file can be split into many parts through secret sharing, reducing this risk to near zero. Watch the contract to see that each piece is still in a node's property. If the contract is still being paid, a cryptographic proof can be provided that someone is still storing the file there.
5.5 Decentralized Autonomous Organizations
he general concept of a "decentralized autonomous organization" refers to a virtual entity with a certain set of members or shareholders, who may own 67% of the majority of the members, and can use the entity's funds and modify its code. Members will collectively decide how the organization should allocate its funds, which may range from bounties, salaries, to even fancier mechanisms (such as an internal currency to reward work) and more.This essentially replicates the legal pitfalls of traditional corporations or nonprofits, but only uses cryptographic blockchain technology to enforce them. So far, discussions about DAOs have revolved around the “ capitalist ” model of a “ decentralized autonomous company ” (DAO), with shareholders receiving dividends and tradable shares. Another option, possibly called a "decentralized autonomous community," would give all members an equal share in decision-making and would require 67% of existing members to agree to add or remove members. As such, the requirement that a person can only have one membership would need to be enforced collectively by the group. A general overview of how to code a DAO is as follows. The simplest design is just a self-modifying piece of code that changes if two-thirds of the members agree to the change. Although in theory the code is immutable, one can easily solve this problem and in fact improve the Operability. In this simple implementation of a DAO contract, there would be three transaction types, differentiated by the data provided in the transaction:
[0, i, K, V] register proposal with index i to change address on storage index K to value V [1, i] vote on proposal i [2, i] If enough votes have been made, then finalize proposal i
The contract will then provide terms for each term. It will keep a record of all Open Storage changes and a list of who voted for those changes. It will also have a list of all members. When any storage change receives a two-thirds vote of the members, the transaction is completed to execute the change. A more sophisticated framework would also have built-in voting capabilities for things like sending transactions, adding and removing members, and could even provide "liquid democracy"-style voting delegation (i.e. anyone can assign someone to vote for it) and distribution). is transitive, so if A assigns B and B assigns C, then C decides A's vote). This design will allow the DAO to grow organically as a decentralized community where people can eventually delegate the task of filtering out who is a member to experts, although unlike the "current system" experts can easily over time Appear and disappear. As individual community members change their alignment.
Another model is a decentralized company where any account can have zero or more shares and requires two-thirds of the shares to make a decision. A complete framework would involve asset management functions, the ability to provide o ers to buy and sell stocks, and the ability to accept o ers (preferably with an in-contract order matching mechanism). Delegations will also exist in the form of liquid democracy, thus encapsulating the concept of a "board of directors".