joshua/dash-website
1
0
Fork 0
mirror of https://github.com/seigler/dash-website synced 2025-07-27 07:16:10 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

edited roadmap

Browse source
This commit is contained in:
Lee Wong 2017-06-27 21:53:58 +07:00 • committed by moocowmoo
parent 908d7804f1
commit 15b2d3dd92
1 changed files with 139 additions and 130 deletions
Download patch file Download diff file Expand all files Collapse all files

241
_i18n/en/_posts/2017-06-27-roadmap.md
View file

@ -6,12 +6,13 @@ title: "OFFICIAL DASH ROADMAP - Version 2.1.1 // Delivery Milestones"
original-author: Evan Duffield
original-link: https://github.com/dashpay/dash-roadmap/blob/master/README.md
---
OFFICIAL DASH ROADMAP
Version 2.1.1 // Delivery Milestones
Evan Duffield / evan@dash.org / Dash Labs
Andy Freer / andy@dash.org / Dash Core CTO
# OFFICIAL DASH ROADMAP
### Version 2.1.1 // Delivery Milestones
<br /><br/>
- Evan Duffield / evan@dash.org / Dash Labs
- Andy Freer / andy@dash.org / Dash Core CTO
<br /><br/>
Dash Evolution will be the first user-friendly and scalable digital currency platform suitable for mass adoption. Because this is such an ambitious goal, we’ve created a detailed roadmap to guide development. Evolution will be launched in three stages. Each release will increase the processing power, ease of use, feature set, and scalability of the network.
@ -31,124 +32,132 @@ Over the past few months we have been rapidly increasing the size of our develop
In order to create a quality product as quickly as possible, the team had to create a solid foundation. We had to carefully plan the project’s roadmap, create enormous amounts of documentation, and do significant research to ensure that we do not make time- and resource-wasting mistakes during the creation of Evolution. We will soon be opening a vast amount of private documentation to the community, ensuring complete transparency of our development work. This phase of the project is coming to a close, with the entire team now beginning to focus on creating the actual codebase for Evolution.
We would also like to announce the creation of a new team to be centered in Hong Kong, called Dash Labs. This team will be the scientific arm of the project, focusing on research and the development of custom hardware. Evan Duffield and Andy Freer are heading up this team. Dash Labs aims to create the first open-source versions of many different types of hardware. Our goal is to help the digital currency space to remain open and transparent, while reducing the economic advantages of closed-source proprietary technology. For example, advanced open-source ASICs would eliminate most of the advantages of privately-developed ASICs. As a result, mining centralization could be significantly reduced. All economic actors will have a level playing field, at least with respect to hardware solutions.
We would also like to announce the creation of a new team to be centered in Hong Kong, called Dash Labs. This team will be the scientific arm of the project, focusing on research and the development of custom hardware. Evan Duffield and Andy Freer are heading up this team. Dash Labs aims to create the first open-source versions of many different types of hardware. Our goal is to help the digital currency space to remain open and transparent, while reducing the economic advantages of closed-source proprietary technology. For example, advanced open-source ASICs would eliminate most of the advantages of privately-developed ASICs. As a result, mining centralization could be significantly reduced. All economic actors will have a level playing field, at least with respect to hardware solutions.
DashPay Wallet Alpha (September 2017)
Dash version of CoPay, pre-Evolution functions, on test-net
Will lead to full Evolution wallet (not merely a web wallet)
DashCore 12.2 Release (September 2017)
2MB block size increase, activation in November 2017
2MB / 5MB block research documentation
Launch of a read-only/view-only portal for project documentation which will be open to the entire community (to ensure transparency)
Launch a read-only/view-only portal to view current tickets, projects the teams are working on
DashPay Evolution Wallet Testnet Release (November 2017)
# DashPay Wallet Alpha (September 2017)
- Dash version of CoPay, pre-Evolution functions, on test-net
- Will lead to full Evolution wallet (not merely a web wallet)
- DashCore 12.2 Release (September 2017)
- 2MB block size increase, activation in November 2017
- 2MB / 5MB block research documentation
- Launch of a read-only/view-only portal for project documentation which will be open to the entire community (to ensure transparency)
- Launch a read-only/view-only portal to view current tickets, projects the teams are working on
User signup and friending process (Signup procedure for Evolution on testnet // reservation testnet)
Basic support for purchase agreements
Evolution Account Management (Create, Review, Update, Delete)
DAPI testnet release
DashCore 12.3 Release (December 2017)
<br /><br/>
# DashPay Evolution Wallet Testnet Release (November 2017)
- User signup and friending process (Signup procedure for Evolution on testnet // reservation testnet)
- Basic support for purchase agreements
- Evolution Account Management (Create, Review, Update, Delete)
- DAPI testnet release
HD wallets, rehaul of networking code, etc etc (other Trac items)
Evolution Alpha Release to Partners (testnet, December 2017)
Integration partner testing
Merchant and app testing
API & SDK testing
Multi-stage escrow transactions
Support for user/merchant ratings via maintenance quorums
DashPay Evolution Wallet Livenet Release (February 2018)
<br /><br/>
# DashCore 12.3 Release (December 2017)
- HD wallets, rehaul of networking code, etc etc (other Trac items)
- Evolution Alpha Release to Partners (testnet, December 2017)
- Integration partner testing
- Merchant and app testing
- API & SDK testing
- Multi-stage escrow transactions
- Support for user/merchant ratings via maintenance quorums
Signup and Friending Process Evolution on Livenet
Evolution Account Management on LiveNet
DAPI Livenet Release
13.0 - Evolution v1 - Mainnet (June 2018)
<br /><br/>
## DashPay Evolution Wallet Livenet Release (February 2018)
- Signup and Friending Process Evolution on Livenet
- Evolution Account Management on LiveNet
- DAPI Livenet Release
Public DashPay, DAPI, DashDrive, DashCore v13.0 release
Fourth Hiring Wave - Full-time developers
500K daily-users supported 22
Ethernet networking requirement 15
1TB HDD / 128GB SSD Req 8 9
64TX/SEC && 5.33MB blocks 16 20 21
Quorum-based DAPI implementation 4
Proof of service / Proof of blockchain
Governance object support for users, groups, accounts
Email-based invitation system 2
State transitions 6
Encryption of object data
Offices in Arizona, Europe (CORE), and Asia (Dash SW)
Age-based quorums 13
Friending system / Semaphore-based approval system 7
IPFS DashDrive implementation / Limited sharding ability
Official user-friendly Wallet
Masternode blocks 11
14.0 - Evolution v2 (TBD)
<br /><br/>
# 13.0 - Evolution v1 - Mainnet (June 2018)
- Public DashPay, DAPI, DashDrive, DashCore v13.0 release
- Fourth Hiring Wave - Full-time developers
- 500K daily-users supported <sup>[22](#f22)</sup>
- Ethernet networking requirement <sup>[15](#f15)</sup>
- 1TB HDD / 128GB SSD Req <sup>[8](#f8)</sup> <sup>[9](#f9)</sup>
- 64TX/SEC && 5.33MB blocks <sup>[16](#f16)</sup> <sup>[20](#f20)</sup> <sup>[21](#f21)</sup>
- Quorum-based DAPI implementation <sup>[4](#f4)</sup>
- Proof of service / Proof of blockchain
- Governance object support for users, groups, accounts
- Email-based invitation system <sup>[2](#f2)</sup>
- State transitions <sup>[6](#f6)</sup>
- Encryption of object data
- Offices in Arizona, Europe (CORE), and Asia (Dash SW)
- Age-based quorums <sup>[13](#f13)</sup>
- Friending system / Semaphore-based approval system <sup>[7](#f7)</sup>
- IPFS DashDrive implementation / Limited sharding ability
- Official user-friendly Wallet
- Masternode blocks <sup>[11](#f11)</sup>
Fifth Hiring Wave - Full-time developers
5M daily-users supported
2TB HDD / 256GB SSD / 16/32 Xeon processor
128TX/SEC && 10.67MB blocks 17
GB Ethernet-handoff / Co-located level networking requirement
Ability to move money between public and private accounts 5
DashDrive v2 3
Governance objects for multi-user accounts (multisig)
Masternode redundancy planning 26
Third-party add-ons for customer DAPI objects / wallet schema versioning
Automatic form filling for delivery addresses using encrypted blobs
External storage support to offload blob storage for payment request history and other information
Fiat / Credit card support from within wallet, seamless design 27
Unofficial Evolution wallets with custom features 23
Evolution marketplace / Add-ons / Rating system 25
Hardened entropy-based wallet seeding system 18
Collateralized mining 12
15.0 - Evolution v3 (TBD)
<br /><br/>
# 14.0 - Evolution v2 (TBD)
- Fifth Hiring Wave - Full-time developers
- 5M daily-users supported
- 2TB HDD / 256GB SSD / 16/32 Xeon processor
- 128TX/SEC && 10.67MB blocks <sup>[17](#f17)</sup>
- GB Ethernet-handoff / Co-located level networking requirement
- Ability to move money between public and private accounts <sup>[5](#f5)</sup>
- DashDrive v2 <sup>[3](#f3)</sup>
- Governance objects for multi-user accounts (multisig)
- Masternode redundancy planning <sup>[26](#f26)</sup>
- Third-party add-ons for customer DAPI objects / wallet schema versioning
- Automatic form filling for delivery addresses using encrypted blobs
- External storage support to offload blob storage for payment request history and other information
- Fiat / Credit card support from within wallet, seamless design <sup>[27](#f27)</sup>
- Unofficial Evolution wallets with custom features <sup>[23](#f23)</sup>
- Evolution marketplace / Add-ons / Rating system <sup>[25](#f25)</sup>
- Hardened entropy-based wallet seeding system <sup>[18](#f18)</sup>
- Collateralized mining <sup>[12](#f12)</sup>
Sixth Hiring Wave - Full-time developers
50M daily-users supported
10 GB Ethernet-handoff / Co-located networking requirement
256TX/SEC && 21.34MB blocks 17
DashDrive sharding / 4TB HD / 512GB SSD
PCI-E hardware-based masternode peripheral 14
Masternode shares via governance objects
Group-based masternode shares program 1
Group-based voting system for picking / dropping hosting providers on group owned masternode
Group-based voting for network proposals
16+ - TBD
<br /><br/>
# 15.0 - Evolution v3 (TBD)
- Sixth Hiring Wave - Full-time developers
- 50M daily-users supported
- 10 GB Ethernet-handoff / Co-located networking requirement
- 256TX/SEC && 21.34MB blocks <sup>[17](#f17)</sup>
- DashDrive sharding / 4TB HD / 512GB SSD
- PCI-E hardware-based masternode peripheral <sup>[14](#f14)</sup>
- Masternode shares via governance objects
- Group-based masternode shares program <sup>[1](#f1)</sup>
- Group-based voting system for picking / dropping hosting providers on group owned masternode
- Group-based voting for network proposals
Complete end-to-end open source masternode hardware / with custom silicon for processing high volumes of payments and other information. Important for maintaining exploit free hardware systems.
Fully open source / ahead-of-curve solutions for ASIC creation, allowing fair distribution and removing proprietary individual investment which creates imbalances in mining hardware 19
v16 - 42.68MB 512TX/S
v17 - 85.36MB 1024TX/S
v18 - 170.72MB 2048TX/S
v19 - 341.45MB 4096TX/S
<br /><br />
# 16+ - TBD
- Complete end-to-end open source masternode hardware / with custom silicon for processing high volumes of payments and other information. Important for maintaining exploit free hardware systems.
- Fully open source / ahead-of-curve solutions for ASIC creation, allowing fair distribution and removing proprietary individual investment which creates imbalances in mining hardware <sup>[19](#f19)</sup>
- v16 - 42.68MB 512TX/S
- v17 - 85.36MB 1024TX/S
- v18 - 170.72MB 2048TX/S
- v19 - 341.45MB 4096TX/S
<br /><br/>
Footnotes
1: Group of savings accounts which correlate to single group-operated masternode
2: Sybil-proof system, where each user created has the ability to invite three others; invitee can’t invite anyone (only proper created accounts using default registration system)
3: Efficient propagation of sub-objects according to user-based quorum filtering
4: DAPI has no access to user’s addresses / only object updates besides the singular pubkey address which is the user’s publicly-visible, address-based identity in the system.
5: ADAPI (private Tor-routed DAPI implementation for PrivateSend)
6: Burn-based credit system for allowing users to update governance objects
7: Friending system has two objects which point to each other, inverting users into/from fields
8: Subject to change according to ASU research
9: HD (disk-based) storage used for DashDrive governance object storage
10: SSD storage used for blockchain-only storage / caches
11: Blockchain-based masternode quorum record / historic accounting of active masternodes at specific times
12: System of requiring collateral + mining hardware to create blocks on network. Each collateral allowed to mine block every specific amount of time.
13: All active masternodes will be sorted into four groups by age. The oldest 25% of the network will be in the first group, the next-oldest 25% will be in the next group, and so on. Masternode quorums will draw 25% of their quorum from each age group.
14: X11 hashing, quorum selection, sha/crypto transaction processing and other common functions available via custom hardware allowing for higher network security and higher transaction support
15: System requires highly interconnected second-tier network with co-located ethernet handoff. VPS co-location should be suffient for first evo release.
16: Upgrade to 5MB blocks doesn't require specialized hardware.
17: Base two log-linear growth model, based on mathematically model of crypto-sphere economy and historical growth of the space.
18: Base two growth model of block sizes beyond this
19: Easy to remember way of seeding wallets
20: Internal budget-based investments to create low nanometer / high quality ASIC hardware which offers bleeding edge advantage to the market, cutting out any ability for private investment to gain large advantage over other miners.
21: State transitions are calculated to be (2007310)*500000/576 bytes, per block, increasing blocksize by 807291 bytes each block, 17% of the total blocksize.
22: Tier-2 conceptually is able to handle much larger block propagation, due to having much higher quality network connections. We plan on having large farms of co-located servers, eventually connected using ethernet hand-off. Masternodes located in the same facility can be used for local syncing, allowing more rapid propagation of blocks to catch new servers up. Tier-1 remains permissionless, but also becomes vastly more expensive. Processing of blocks uses custom hardware, allowing for us to process transaction/transition signatures in a parallelized way.
23: 868 transactions per block, if assumed 1 transaction per day, per user (lots of assumptions // we need more data). (5TX/SEC + 2TS/SEC)
24: Second-generation Evolution wallets are software based wallets which expand the object schema to allow internal wallet-to-wallet custom relationships for custom applications such as allowing businesses to have custom wallets for their application. This will allow streamlined applications with easy to use features within subsets of the whole dash economy.
25: DashDrive object writes require fees for each object written to the system. The system is designed to use an initial burn of coins, which create a small credit that is tracked in the system, debits are introduced for each operation that is done in relation to Evolution.
26: Using specialized state transition for maintenance functions Each component of masternode will run redundantly under a load balancer to allow for individual component failure without causing a cascade which creates an outage
27: Using third party API keys, allowing user to setup keys in settings then use from wallet seamlessly without ever leaving Dash.
28: By leveraging dapi and third party tools, we can deploy addons and a marketplace, which allows custom third party services to integrate directly in the wallet such as debit/credit cards and fiat bank account support
<br /><br/>
<br /><span id="f1">1</span>: Group of savings accounts which correlate to single group-operated masternode
<br /><span id="f2">2</span>: Sybil-proof system, where each user created has the ability to invite three others; invitee can’t invite anyone (only proper created accounts using default registration system)
<br /><span id="f3">3</span>: Efficient propagation of sub-objects according to user-based quorum filtering
<br /><span id="f4">4</span>: DAPI has no access to user’s addresses / only object updates besides the singular pubkey address which is the user’s publicly-visible, address-based identity in the system.
<br /><span id="f5">5</span>: ADAPI (private Tor-routed DAPI implementation for PrivateSend)
<br /><span id="f6">6</span>: Burn-based credit system for allowing users to update governance objects
<br /><span id="f7">7</span>: Friending system has two objects which point to each other, inverting users into/from fields
<br /><span id="f8">8</span>: Subject to change according to ASU research
<br /><span id="f9">9</span>: HD (disk-based) storage used for DashDrive governance object storage
<br /><span id="f10">10</span>: SSD storage used for blockchain-only storage / caches
<br /><span id="f11">11</span>: Blockchain-based masternode quorum record / historic accounting of active masternodes at specific times
<br /><span id="f12">12</span>: System of requiring collateral + mining hardware to create blocks on network. Each collateral allowed to mine block every specific amount of time.
<br /><span id="f13">13</span>: All active masternodes will be sorted into four groups by age. The oldest 25% of the network will be in the first group, the next-oldest 25% will be in the next group, and so on. Masternode quorums will draw 25% of their quorum from each age group.
<br /><span id="f14">14</span>: X11 hashing, quorum selection, sha/crypto transaction processing and other common functions available via custom hardware allowing for higher network security and higher transaction support
<br /><span id="f15">15</span>: System requires highly interconnected second-tier network with co-located ethernet handoff. VPS co-location should be suffient for first evo release.
<br /><span id="f16">16</span>: Upgrade to 5MB blocks doesn't require specialized hardware.
<br /><span id="f17">17</span>: Base two log-linear growth model, based on mathematically model of crypto-sphere economy and historical growth of the space.
<br /><span id="f18">18</span>: Base two growth model of block sizes beyond this
<br /><span id="f19">19</span>: Easy to remember way of seeding wallets
<br /><span id="f20">20</span>: Internal budget-based investments to create low nanometer / high quality ASIC hardware which offers bleeding edge advantage to the market, cutting out any ability for private investment to gain large advantage over other miners.
<br /><span id="f21">21</span>: State transitions are calculated to be (200*73*10)*500000/576 bytes, per block, increasing blocksize by 807291 bytes each block, 17% of the total blocksize.
<br /><span id="f22">22</span>: Tier-2 conceptually is able to handle much larger block propagation, due to having much higher quality network connections. We plan on having large farms of co-located servers, eventually connected using ethernet hand-off. Masternodes located in the same facility can be used for local syncing, allowing more rapid propagation of blocks to catch new servers up. Tier-1 remains permissionless, but also becomes vastly more expensive. Processing of blocks uses custom hardware, allowing for us to process transaction/transition signatures in a parallelized way.
<br /><span id="f23">23</span>: 868 transactions per block, if assumed 1 transaction per day, per user (lots of assumptions // we need more data). (5TX/SEC + 2TS/SEC)
<br /><span id="f24">24</span>: Second-generation Evolution wallets are software based wallets which expand the object schema to allow internal wallet-to-wallet custom relationships for custom applications such as allowing businesses to have custom wallets for their application. This will allow streamlined applications with easy to use features within subsets of the whole dash economy.
<br /><span id="f25">25</span>: DashDrive object writes require fees for each object written to the system. The system is designed to use an initial burn of coins, which create a small credit that is tracked in the system, debits are introduced for each operation that is done in relation to Evolution.
<br /><span id="f26">26</span>: Using specialized state transition for maintenance functions Each component of masternode will run redundantly under a load balancer to allow for individual component failure without causing a cascade which creates an outage
<br /><span id="f27">27</span>: Using third party API keys, allowing user to setup keys in settings then use from wallet seamlessly without ever leaving Dash.
<br /><span id="f28">28</span>: By leveraging dapi and third party tools, we can deploy addons and a marketplace, which allows custom third party services to integrate directly in the wallet such as debit/credit cards and fiat bank account support