Author Topic: 目前已知的DAC经常利用的技术有哪些?  (Read 4523 times)

0 Members and 1 Guest are viewing this topic.

Offline sfinder

  • Hero Member
  • *****
  • Posts: 1205
  • 4 Cores CPU+100GB SSD+anti-DDoS Pro
    • View Profile
3I的DAC列表。

where can i find the list for upcoming DAC chains?
will angel-share donation still be on until reach 200 days  ? if 02/28's btsx snapshot is successful then future donation to AGS will not be able to get BTS ,right ?


then what?

Then when you download BitShares X and open your wallet you will get your starting balance.

What happens on February 28th is only relevant to the first chain of Bitshares; all other Bitshares chains will be released in the future after February 28th. Invictus DAC's will be distributed to PTS holders and those who donate to AGS if the donation comes in before each one is released. So if you donate after February 28 you will be still in line to benefit from all the other chains and DAC's that are upcoming.


BitShares X - many of them with different variations and assets.
BitShares DNS - auction off domain names (one chain)
BitShares Bingo - (many chains)
BitShares Tunes - See recent thread about music / etc (many chains)
BitShares Vote - (many chains)
BitShares Me - Issue your own shares. (many chains )
BitShares Reddit - (many chains)
BitShares Ads  - ad words ...

There are not white papers on these yet, but you can see there is plenty of work to do and lots of value to be produced for AGS and PTS holders.
微博:星在飘我在找|BTS X 受托人delegate ID:baidu
中国教育书店合作将20%收入捐献给贫困山区学生。
Cooperating with China Education Bookstore and will donate 20% of delegate income to the poor students

Offline nametooshort

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
关于实现Blockchain所用的DB,有很多有趣的讨论,Bitcloud最近比较活跃,有一些讨论,不同于levelDB和BDB此类key-value db, 有尝试用Sqlite此类的关系数据库:

Quote
Javier R. Sobrino liberman@riseup.net via lists.sourceforge.net
11:58 PM (10 hours ago)

to Bitcloud

While I was designing the blockchain for Bitcloud, I realized that there
is no way that Bitcloud can work on a classical Blockchain structure.

Just imagine: Bitcoin with 1 million users needs 12Gbytes of data to
store the blockchain, and what it stores is just money
transactions. Bitcloud is going to store many other things, like node
statistics, user and publishers information, sophisticated contracts,
etc. If we use an immutable form of blockchain, in one month after the
release we will need hundreds of gigabytes only to store that.

Another limitation of the classical blockchain is that it is not
relational, so you can't do advanced queries without going into a lot
code. To see that, look at how I am designing the nodepool here:

https://github.com/wetube/bitcloud/blob/master/src/c/nodepool.sql

Handling the logic of all of that in a key-value database is very hard.

So my proposition here is to stop thinking in terms of the classical
blockchain and approach this project from a different perspective.

As I say in the paper: the Nodepool is a relational database, synced by
consensus, in which all the statistics, information and contracts are
stored.

In my investigations to find a proper database that could support all
the things we need, I found that SQLite is very nice, and can be easily
tweaked and extended.

SQLite supports the creation of custom checks, so something like this
can be possible:

CREATE TABLE publisher_grid_contracts (
 id BLOB(16) PRIMARY KEY NOT NULL,
 publisher TEXT NOT NULL REFERENCES publishers(public_key),
 grid TEXT NOT NULL REFERENCES grids(public_key),
 -- Signatures of this contract:
 publisher_sig TEXT NOT NULL,
 grid_sig TEXT NOT NULL,
 -- Terms:
 min_storage INTEGER NOT NULL,
 min_bandwidth INTEGER NOT NULL,
 start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
 end_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
 availability INTEGER NOT NULL, -- % of time online
 ping_average INTEGER DEFAULT 0,
 -- Coin terms
 coin REFERENCES coins(id)
 CHECK (signatures(publisher_sig, grid_sig,
   publisher || grid || min_storage || min_bandwidth ||
   start_date || end_date || availability || ping_average ||
   coin )
);

Look at the last statement, the "CHECK(signatures...." one. Once we
define the extension "signatures" in plain C, we can ensure that nobody
can insert a contract into the database without the proper signature of
the two participants of the contract.

But there is even more. SQLite also allows to customize an authorization
function to allow or deny access to data from different sources, which
means that we can base the language of Bitcloud in SQL, and only allow
certain operations. Look at:
http://www.sqlite.org/capi3ref.html#sqlite3_set_authorizer

I strongly recommend everybody to have a look at this fantastic book:

http://evalenzu.mat.utfsm.cl/Docencia/2012/SQLite.pdf


Now, having SQLite resolving our problems for the language and the
database, we can concentrate on the sync process.

Any suggestion, questions or alternatives to all of this, please answer
to the list.

Thanks.

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Bitcloud-developers mailing list
Bitcloud-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcloud-developers
淘京币用的就是levelDB
Even if writing Protoshare address in signature is not something good,
PvDZqsSyAsCDYNyYCfwZmy19EVohxnbnKB

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
关于实现Blockchain所用的DB,有很多有趣的讨论,Bitcloud最近比较活跃,有一些讨论,不同于levelDB和BDB此类key-value db, 有尝试用Sqlite此类的关系数据库:

Quote
Javier R. Sobrino liberman@riseup.net via lists.sourceforge.net
11:58 PM (10 hours ago)

to Bitcloud

While I was designing the blockchain for Bitcloud, I realized that there
is no way that Bitcloud can work on a classical Blockchain structure.

Just imagine: Bitcoin with 1 million users needs 12Gbytes of data to
store the blockchain, and what it stores is just money
transactions. Bitcloud is going to store many other things, like node
statistics, user and publishers information, sophisticated contracts,
etc. If we use an immutable form of blockchain, in one month after the
release we will need hundreds of gigabytes only to store that.

Another limitation of the classical blockchain is that it is not
relational, so you can't do advanced queries without going into a lot
code. To see that, look at how I am designing the nodepool here:

https://github.com/wetube/bitcloud/blob/master/src/c/nodepool.sql

Handling the logic of all of that in a key-value database is very hard.

So my proposition here is to stop thinking in terms of the classical
blockchain and approach this project from a different perspective.

As I say in the paper: the Nodepool is a relational database, synced by
consensus, in which all the statistics, information and contracts are
stored.

In my investigations to find a proper database that could support all
the things we need, I found that SQLite is very nice, and can be easily
tweaked and extended.

SQLite supports the creation of custom checks, so something like this
can be possible:

CREATE TABLE publisher_grid_contracts (
 id BLOB(16) PRIMARY KEY NOT NULL,
 publisher TEXT NOT NULL REFERENCES publishers(public_key),
 grid TEXT NOT NULL REFERENCES grids(public_key),
 -- Signatures of this contract:
 publisher_sig TEXT NOT NULL,
 grid_sig TEXT NOT NULL,
 -- Terms:
 min_storage INTEGER NOT NULL,
 min_bandwidth INTEGER NOT NULL,
 start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
 end_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
 availability INTEGER NOT NULL, -- % of time online
 ping_average INTEGER DEFAULT 0,
 -- Coin terms
 coin REFERENCES coins(id)
 CHECK (signatures(publisher_sig, grid_sig,
   publisher || grid || min_storage || min_bandwidth ||
   start_date || end_date || availability || ping_average ||
   coin )
);

Look at the last statement, the "CHECK(signatures...." one. Once we
define the extension "signatures" in plain C, we can ensure that nobody
can insert a contract into the database without the proper signature of
the two participants of the contract.

But there is even more. SQLite also allows to customize an authorization
function to allow or deny access to data from different sources, which
means that we can base the language of Bitcloud in SQL, and only allow
certain operations. Look at:
http://www.sqlite.org/capi3ref.html#sqlite3_set_authorizer

I strongly recommend everybody to have a look at this fantastic book:

http://evalenzu.mat.utfsm.cl/Docencia/2012/SQLite.pdf


Now, having SQLite resolving our problems for the language and the
database, we can concentrate on the sync process.

Any suggestion, questions or alternatives to all of this, please answer
to the list.

Thanks.

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Bitcloud-developers mailing list
Bitcloud-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcloud-developers
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline nametooshort

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
实际上可以不使用区块链构建一个DAC。区块链的一个重要作用是让每个人都看得见所有数据。而邮件之类的DAC实际上可以不使用区块链来构建。
去中心化实际上是为了防止单点失效。在中心化的系统里,要是中心服务器down掉了,整个系统就down掉了。
Even if writing Protoshare address in signature is not something good,
PvDZqsSyAsCDYNyYCfwZmy19EVohxnbnKB

Offline Musewhale

  • Hero Member
  • *****
  • Posts: 2881
  • 丑,实在是太丑了 !
    • View Profile
MUSE witness:mygoodfriend     vote for me

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
技术核心有3点:安全、透明、加密。这3点的核心就是 blockchain 技术了。

重点关注:
1. 安全性和确认速度的平衡。pos、pow、共识技术讨论
2. 中心化和去中心化之间的平衡。
我所理解的去中心化目的主要是为了数据公开透明和网络的安全。但它给每个节点权利的同时,也对每个节点提出了更高要求。
比如keyhotee的邮件功能,只有在每个节点永远保持在线时才是最高效的。只要有节点离线,就会产生广播数据,我的节点必须收取全网所有数据,流量很吓人。
我认为对邮件服务,完全可以由中心服务器承担,只要客户端发给它的都是加密数据就够了。
现在的主观点流似乎是要把去中心化做到极致,有点为了去中心化而去中心化的意思,我不太理解。


其它都是具体的应用模型的设计,比如
1. 交易系统中:红利、利息、交易费、撮合算法、初始分配、抵押。。。。
2. 通信系统:p2p 通信
3. 存储:分布式数据

最关键DAC:ID和交易。3I确实有眼光。只需要把这两个整合进来,很多中心服务器提供的应用都能获得新的生命。

Offline nametooshort

  • Jr. Member
  • **
  • Posts: 46
    • View Profile
Ripple的共识机制就是靠节点投票(这就是为什么ripple需要用钱激活钱包),就是爆发编辑战的时候锁页面然后到讨论里去继续大战投票(看伪基百科多和谐)……
Even if writing Protoshare address in signature is not something good,
PvDZqsSyAsCDYNyYCfwZmy19EVohxnbnKB

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
1. BlockChain: 去中心化的分布式数据库,特点是更新慢,查询快?(中本聪的主要贡献)
基于POS或者POW的挖矿模型也只是这个中数据库的一个组成部分? 其表现形式只是不同的更新维护BlockChain的算法
还有基于最长链的唯一性,解决双重支付的问题,反应到数据库就是唯一性的问题(维基百科解决这个问题有时会引发编辑大战,是否也可以称作Prove of Editing?)
元数据的定义,比如(比特资产的数字化表示)

2. 非对称加密,私钥公钥,解决用户隐私安全等很多问题?具体包括哪些?(现代金融业已广泛应用)

3. 点对点的同步blockchain,NodePool,网络拓扑,去中心化的解决

4. 点对点的信息传输,比如BitMessage的解决方案,Keyhotee的解决方案(借助relay server?)?
信息传输和数据库还是不一样的,信息最终也许只存在特定的节点上面,而非所有节点可查询

5. Ripple的共识机制又是怎么回事?

欢迎补充,发现我们经常是从各个DAC的角度分析比较,也许可以从更细粒度的角度分析分析他们都使用了哪些共同的机制或技术?
« Last Edit: February 11, 2014, 05:55:08 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.