2019年五大最期待的区块链项目

  • 0_1547624377303_dac02041-24d9-490e-aa71-ca0d29843148-image.png


    时光荏苒,岁月如梭,区块链至今已发展了十年的时间。回首过去,在过去的一年里,整个行业都让人极其失望,币价连续暴跌,在2017年看似火爆的数字货币和无所不能的区块链也都熄了火,2018年年初甚至还有人质疑区块链项目的白皮书,到了年末的时候,白皮书更是无人关注,许多区块链信仰者纷纷惨淡离场,甚至“装死”不在关注行业动态的大有人在。

    --

    区块链真的凉了吗?其实不然。任何新的技术或新的事物都会经历曲折。区块链也是如此,虽然发展道路离奇曲折,但其前途却是光明的。2018年对于区块链来说是“去泡沫”的一年,虽然诸多区块链项目纷纷折戟沉沙,但区块链却也在很多领域中展现出了非凡的实力,覆盖了包括金融、物流、食品等多个领域,更是包含了阿里、腾讯、百度、华为、高盛等百余家顶级公司。

    --

    2019年起虽然比特币等各类数字货币价格并未有太多回升,但有不少分析师表示2019币圈熊市必将散去、牛市也将重归。与其关联密切的区块链技术也将有更大的突破,在更多场景得到应用,那2019年又有哪些技术最值得期待呢?


    1、IPFS+Filecoin

    --
    IPFS+Filecoin是当之无愧的领军项目,之所以说其是领军,主要因为IPFS是个很牛的协议,像HTTP那样负责寻址,没有代币(当然前提是要做成功的)!Filecoin才是那个负责存储数据的链(上面是有代币的)。

    --

    IPFS+Filecoin原计划是于在18年上主网,却拖到了2019年,其实IPFS在18年的整体进度是大家有目共睹的,测试网运行良好,在几个月前还和互联网大佬Cloudflare合作推出了Cloudflare网关。不出意外,今年就可见到正式主网启动,以及对于分布式存储领域新篇章的开启。

    --

    2018年,众多公链潮起潮落,唯独Filecoin代表的区块链存储方向社区,一直十分活跃。而飞迩科一直是区块链存储生态的重要玩家。上网后,其公链的分布式矿机,将由飞迩科团队与其强强联手,IPFS+Filecoin有了飞迩科的加盟可谓如虎添翼,这也难怪其项目能列为2019年最受期待的区块链项目榜首。


    2、Certik

    --
    Certik是用形式化验证为智能合约和区块链生态提供安全验证服务,其基于的CertiKOS是世界上第一个经过全面验证的防黑客操作系统。美国国防部曾聘请谷歌团队对CertiKOS进行攻击,但结果毫无意外,攻击了一个月都并未成功,而CertiKOS的主要开发者正是Certik的创始人顾荣辉。

    --

    目前区块链安全市场可以说还处于蓝海阶段,隐私和安全领域的区块链项目融资占比只有1%,主要原因还是因为安全是区块链行业门槛较高的领域,但未来链上跑的几十万、甚至百万个DAPP都是需要安全审计的,这可以说是一个千亿美元的大市场,行业都在“裸奔”,不出问题还好,一旦出了问题就是几亿美元的大事件!


    3、Algorand

    --
    在区块链如此寒冬的背景下,Algorand在去年10月24日获得4.3亿元的融资,投资机构的logo放满整个屏幕,众多投资机构看中的无非就是其创始团队。其创始人Silvio Micali是MIT教授、更是零知识证明的联合提出者,因在密码学领域的突出贡献于2013年荣获图灵奖。虽然在学术团队一直有着众多的质疑,但诸多机构还是不愿放弃;此外,Algorand的代币发行计划还未公开。


    4、 Starkware

    --
    Starkware提供了基于Stark技术的区块链技术解决方案,利用零知识证明协议保护链上信息隐私。Starkware是一个以色列项目,创始人是Zcash前开发人员,目前整个团队都是以色列人,目前团队也在以色列。该项目一个月时间便获得600万美元种子轮融资(其中包括V神,Vitalik Buterin),近期又宣布获Paradigm 领投融资3000万美元,因特尔创投、红杉、Atomico、丹华资本等国际一线资本跟投。


    5、Celer

    --

    Celer是链下状态通道解决方案,旨在将互联网规模带入区块链。目前可扩展性不足是区块链走向主流的一个重大障碍,而链下状态通道是区块链可扩展性解决方案中最有潜力的技术路径之一,这亦是该项目能够获得丹华投资、FBG、BlocKVC、Pantera和Stable等投资机构青睐的主要原因。

    其实早在比特币上就有闪电网络、以太坊则有雷电网络,Celer在此前的模拟测试中,性能却优于前者的30倍,更有人称Celer是“中国加强版的Raiden”;此外,Celer作为一项链下解决方案,本身并无公链,而是服务于所有的公链。


    【往期文章】


    识别二维码进入IPFS社群

    0_1547624742403_d964ff95-ed14-47de-95ad-a85e5356457e-image.png

Log in to reply
 

Email:filapp@protonmail.com

Twitter:

https://twitter.com/RalapXStartUp

Telegram:

https://t.me/bigdog403

全球Filecoin中文爱好者网站

  • X

    It has come to my attention that storage clients wish to obtain the CommD and CommR associated with the sector into which the piece referenced in their storage deal has been sealed. The client can already use the query-deal command to obtain the CID of the commitSector message corresponding to that sector - but message wait doesn't show individual commitSector arguments - it just shows some string encoding of the concatenated arguments' bytes.
    I propose to augment the ProofInfo struct with CommR and CommD such that the storage client can query for their deal and, when available, see the replica and data commitments in the query-storage-deal command. Alternatively, the query-storage-deal code could get deal state from the miner and use the CommitmentMessage CID to look up CommR and CommD (on chain) - but this seems like more work than is really necessary.

    阅读更多
  • X

    Hmmmm. These are just my thoughts off the cuff:

    For straight-ahead performance that's not specifically concerned with the issue of loading the data (from wherever), then work on smaller (1GiB) sectors is okay. When considering optimization for space so that large sectors can be replicated, 128GB for >1GiB sectors is obviously problematic from a normal replication perspective. However, if we consider the attacker who wants to replicate fast at any cost, then maybe it's okay.
    Based on this, we could probably focus on smaller sectors as a reasonable representation of the problem. This has the unfortunate consequence that the work is less applicable to the related problem of speeding replication even when memory must be conserved to some extent.
    I guess as a single datum to help calibrate our understanding of how R2 scales, it would be worth knowing exactly how much RAM is required for both 1GiB and (I guess) 2GiB. If the latter really fails with 128GB RAM, how much does it require not to? If the work you're already doing makes it easy to get this information, it might help us reason through this. I don't think you should spend much time or go out of your way to perform this investigation though, otherwise.
    Others may feel differently about any of this.

    阅读更多
  • X

    @xiedapao
    If there does exist such a thing, I cannot find it.

    zenground0 [7 hours ago]
    I don't believe there is

    zenground0 [7 hours ago]
    tho maybe phritz has some "refactor the vm" issues that are relevant

    laser [7 hours ago]
    I assert to you that we must create an InitActor in order for CreateStorageMiner conform to the specification.

    Why [7 hours ago]
    I’ll take things I don’t disagree with for $400 Alex

    zenground0 [7 hours ago]
    Agreement all around. However this is one of those changes that is pretty orthogonal to getting the storage protocol to work and something we can already do. We need to track it but I see it as a secondary priority to (for example) getting faults or arbitrating deals working.

    anorth [3 hours ago]
    Thanks @zenground0, I concur. Init actor is in our high-level backlog, but I'm not surprised there's no issue yet. Is it reasonable to draw our boundary there for now?

    阅读更多
  • X

    Does there already exist a story which addresses the need to create an InitActor?

    阅读更多

Looks like your connection to Filecoin.cn中国爱好者社区 was lost, please wait while we try to reconnect.