Descrption：Lisk makes it easy for developers to build and deploy blockchain applications in JavaScript.
Lisk
v1
Principle and design goals
Lisk is the first decentralized application solution written entirely in Node.js. This opens up the Lisk ecosystem to thousands of current developers with no additional skills necessary. Any web developer who is already familiar with JavaScript and Node.js can immediately jump in and begin building decentralized applications from day one.
Our core goal with Lisk was to create an entire plug and play system that would allow developers to do everything from design, development, publication, and monetization, all from within one platform. By utilizing the Lisk ecosystem, developers can quickly deploy their JavaScript apps to Lisk Hosting & Storage Nodes, gain listing in the Lisk Dapp Store, and have immediate access to Lisk Compute Nodes for execution of the code. All while being backed by the integrity and security of the Lisk sidechain consensus functionality.
To top it all off, all of these cloud functions are run by the users and Lisk delegates who are paid through a built in invoice system (or by the network itself in the case of delegates) and paid in LISK (Lisk’s own cryptocurrency) or BTC. It truly is a one stop shop for application development that provides a cutting edge, affordable, and forward-thinking solution.
Technology implementation
Consensus mechanism
Lisk is based on the DPoS(Delegated Proof of Stake) consensus mechanism. This method of consensus was originally created by the BitShares team.
DPoS is based on delegates creating blocks. Delegates are trusted accounts which are elected to be “Active Delegates”. The 101 delegate accounts with the most votes create the blocks. Other delegates are listed as “Standby Delegates”, and can advance to the top 101 list by receiving votes from the other Lisk owners. All users of Lisk have 101 votes available to elect their favorite delegates into the top 101 list. The weight of each of the 101 votes is proportional to the amount of LISK the user has in the wallet the votes are cast from. This total amount is shown on the delegate list as an “Approval”, and is listed as a percentage of the 100 million LISK available that is voted for that delegate.
Delegate promotion to the top 101 or demotion to the standby list happens at the completion of the 101 block generation cycle. Each cycle of 101 blocks is created by the top 101 delegates in random order. The block time is 10 seconds. Newly created blocks are broadcast to the network and added to the blockchain. After 6 to 10 confirmations, a block, along with its transactions, can be considered as confirmed. A complete 101 block generation cycle takes approximately 16 minutes.
In DPoS, forks can occur, but the longest fork wins. Delegates must be online all of the time and have sufficient uptime. Uptime is used to catalogue the reliability of a node by logging each time that it misses a block that was assigned to it. Users vote for the top 101 delegates based on several factors, uptime being one key factor used to make a determination. If a delegate drops below a certain rating, users may remove votes from the delegate in question due to poor performance.
Accounts and transactions
Lisk Transactions
An overview of the transactions available on Lisk's network are shown below. The different transaction types are explained in detail in the respective sections below. Some transaction types are currently disabled (as of 1.0 Core version) since the corresponding functionality is not implemented yet.
| Type | Status | Purpose | Fee |
|---|---|---|---|
| 0 | active | Transmit funds to a specified Lisk address | 0.1 LSK |
| 1 | active | Register a second passphrase | 5 LSK |
| 2 | active | Register a delegate | 25 LSK |
| 3 | active | Submit vote(s) for delegates | 1 LSK |
| 4 | active | Multisignature registration | 5 LSK per key in keysgroup |
| 5 | active | Register an application on the blockchain | 25 LSK |
| 6 | disabled | Transfer Lisk into a sidechain | 0.1 LSK |
| 7 | disabled | Transfer Lisk out of a sidechain | 0.1 LSK |
Transaction Signing
Every transaction, regardless of the type, must be signed by the sender prior to being accepted by the network. The process of signing the transaction is identical for every transaction. First, a data block representing the transaction must be generated. Each data block contains a specific set of standardized information. Additional information contained in the data block will differ depending on the type of the transaction.
The following fields must be present in all types of transactions:
- A 8 bit integer identifying the type of the transaction
- A 32 bit epoch timestamp of when the transaction has been created
- The 256 bit public key of the issuer of the transaction
- A 64 bit integer representing the amount of Lisk to be transferred
The other fields will be added to this schema depending on the transaction type. Once the data block has been generated, it is hashed using the SHA-256 algorithm, and this hash is signed using the key pair of the issuer. If the issuer has enabled a second passphrase, the first signature is appended at the end of the data block, and the process is repeated, generating a second signature. The same concept applies to multisignature accounts. The transactionID is generated from the data block. In order to compute the transactionID the system takes the data block with the completed signature information and hashes this block using SHA-256 and the first 8 bytes of the hash are reversed and which is then used as the transactionID.
Smart contract system
Lisk allows users to maintain a contact or friends list. This feature can be used to store frequently used accounts, but can also be used as a reputation system. If an account has many confirmed contacts, it may be considered more reputable than one without.
Contacts work like followers on Twitter. A user is added to the contact list, which will then show as a pending contact request in the user's wallet. Regardless of whether or not the other user accepts the request, they will be shown in the contact list. Once the other user accepts the request, the requester will be added to his contact list as well. Both parties now have a new confirmed contact.
The network fee for adding a new contact or accepting an incoming request is 1 LISK.
Cryptography
Distributed storage protocol
Cross-chain and exchange technology
Special technology
Economic model and incentive
Governance mechanism
Applications
1. Virtual Machine
2. Dapps
3. Dapps Development
4. Dapps Computation
5. Dapps Consensus
6. Dapps Master Nodes
7. Dapps Storage
8. Dapps Deposits / Withdrawals
9. Dapps Tokens
Contributors
No contributors information for the version. to see perfessional version!
Comment
| Rank | Blochchain | Similarity |
|---|---|---|
|
1st
|
GNT
|
22.353288% |
|
2st
|
XAS
|
22.0777766666667% |
|
3st
|
DRGN
|
21.826408888888903% |
|
4st
|
FCT
|
21.4004255555556% |
|
5st
|
BTM
|
21.312877619047597% |
No analysis results for the version. to see perfessional version!
| Rank | Blochchain | Similarity |
|---|---|---|
|
1st
|
RLC
|
5.0819% |
|
2st
|
TKY
|
4.688% |
|
3st
|
SMT
|
3.35% |
|
4st
|
ZIP
|
3.2043000000000004% |
|
5st
|
XZC
|
3.1845% |
Name:
Company:
Email:
Location:
Repos:
Followers: