PocketWPは、暗号資産(暗号通貨/仮想通貨)の情報を
整理・ストックするサービスです(β)
Crypto | BlockNet (BLOCK) Whitepaper(2/2)
edit 編集

Crypto | BlockNet (BLOCK) Mobile Size Whitepaper(2/2)

Abot CORE COMPONENTS

Design | CORE COMPONENTS

BLOCKCHAIN SERVICES

Blockchain services supplement the general-purpose core services to support specific use cases. Since there is no limit  to the number of inter-chain services that may be created on the Blocknet, there is no definable limit the number of  blockchain services that third parties may build.

Block DX, the first inter-chain dapp on the Blocknet, requires several blockchain services. These shall be introduced, both  in order to document them, and to illustrate something of the nature of a blockchain service.

Overview of Block DX Blockchain Services

To function as an exchange requires several services over and above an atomic swap between counterparties. In fact, any  exchange (centralized or decentralized) must provide four key functions:

  • capital storage
  • order broadcast
  • order matching
  • settlement

Since Block DX is a decentralized exchange, it follows necessarily that all four of these functions must be decentralized (in  addition to some broader aspects pertinent to decentralization, like maintaining a fully open source codebase and  virtually anyone being able to list a coin). With atomic swaps, the decentralized exchange service decentralizes both  capital storage and settlement a priori. However, atomic swaps do not amount to an exchange on their own; order  broadcast and matching must be decentralized in addition. It is these that are supported by blockchain services:

  • Order broadcast is decentralized by leveraging the service lookup service, which is entirely peer-to-peer  throughout.
  • Order matching is performed locally by each trader’s dapp, which are orchestrations of the core components and one or more blockchain components.

The principal design consideration for order broadcast and matching is that, like other peer-to-peer systems, they are  naturally vulnerable to DOS (denial-of-service) attacks. In an analogous manner to how Bitcoin functions as an electronic  cash system that solves the Byzantine Generals’ problem, a workable solution must amount to a quality-of-service  guarantee about orders on the book. Secondly, one of the design considerations in the token ecosystem is how to  monetise service, since in a decentralized ecosystem, if business models are not cryptoeconomically sound, they are  not sound at all. What follows is an introductory discussion that frames these problems, and the Blocknet’s solution to  them.

Decentralizing An Order Book

Note: the following sections detail the Blocknet’s candidate order system. While other systems are under consideration, the  current one is included in order to introduce the design space in which decentralized order systems exist, and to encourage  comment and contribution in this new area.

An order book is analogous to a notice board upon which traders may add liquidity by posting bids or asks, and from  which other traders may take liquidity by consuming bids or asks. Along with the acts of posting orders to the book or  taking them come commitments to settle accounts once a match is made. Now in a decentralized context, an order book  becomes essentially a public notice board, upon which anyone is free to post an order, where no central party controls  people posting, and whose intentions need not be to trade non-maliciously.

As such, a decentralized order book requires (a) a means of ensuring that only good orders are posted to it (that is, it  must prevent order spam), and (b) that if an order is matched, the counterparties are compelled to honour their  commitments to settle (that is, it must prevent order-DOS). Now, surprisingly, blockchain is not a good technology to use  for an order book, for two reasons: firstly, order books need to operate extremely quickly – at the very least, supporting a  realtime user experience – but blockchains require a transaction (generally put, a truth-claim) to be at least several blocks  deep in the chain before its truth is sufficiently established. Secondly, since blockchains require mining or staking to  establish truth, this opens an opportunity for miners to gain privileged access to order information, and potentially to  frontrun, favouring the matching of their orders if they mine the next block. As a result, a different system is required to  decentralize orders.

A final novel fact about an order book is that, because orders are commitments to a future settlement act, no funds are  sent or risked throughout the order broadcast and matching process, so parties using an order system are exposed to a  far lesser degree of risk than that of payments or settlement. This offers an advantage in the design of an order system,  as it is not necessary to accept the crippling performance penalty that the use of a blockchain would impart; the system  may function successfully while tolerating a certain degree of untruthfulness. As such, the design requirement is, as a  minimum standard, to prevent illicit activity from scaling beyond isolated acts. Specifically, the Blocknet solution:

  • 1.Supports UTXO verification, that is, that coins offered in an order are spendable.
  • 2.Renders order spam unscalable, specifically via a hashcash-style trade fee that has minimal impact upon honest  traders but makes spam significantly costly.
  • 3.Renders order-DOS unscalable, in the same manner as in (b).
  • 4.Renders Service Node collusion economically infeasible (see special properties of Service Nodes).
  • 5.Supports partial order matching, enabling several counterparties  to consume an order without the  abandonment of one trade locking the entire order until the refund transaction becomes spendable. This can  supplement a trading strategy that avoids the opportunity cost of a counterparty abandoning a single high value  trade by spreading capital over several orders across a price range.

What Do Decentralized Orders Look Like? - Self-Sovereignty

We hold that decentralization, in the context of orders, amounts to preserving self-sovereignty between actors on the  decentralized exchange. Decentralization is not a well-understood term, and is frequently conflated with “distribution”  and muddled up with notions pertaining to reaching consensus. Decentralization, as Vitalik Buterin explains clearly, is  fundamentally about control:a decentralized system places no party under the control of another, except where the  matter under concern is a shared resource, in which case all parties participate as equals. Distribution, by contrast, is  simply spreading a task or role between several parties, regardless of whether any one party controls this. Finally,  consensus between parties strictly pertains to the reaching of agreement about a fact or action, not to whether work is  distributed or control decentralized. This does not imply, though, that to decentralize Bitcoin does not require the  reaching of consensus about which transactions are legitimate, and that work is not distributed over the edges of its  network. These factors are necessary but not sufficient to the decentralization of Bitcoin.

Decentralizing a currency is analogous to decentralizing orders where self-sovereignty is encountered in the former: in the  same way that any holder of bitcoins may send coins without third-party control, any trader may add liquidity to the  order book or take liquidity from it; in the same way that Bitcoin users may prove to themselves that a given coin was  sent at a given time, counterparties may verify the validity of orders and order-acceptance messages on their own.  However, the analogy with cryptocurrency ends upon consideration of the fact that orders are offers to send coins, which  require a future counterparty to consume them, and involves a matching process. Because a match requires the parties  involved to mutually sign an order-acceptance message, and because no other entities need be required to establish that  an order is matched, peers on a network may determine and discover the state of orders on a purely self-sovereign basis,  without requiring a consensus algorithm (e.g. proof-of-work).

We propose an entirely self-sovereign order system design, involving three parties. Below is a cursory overview, which  shall be developed upon as the discussion progresses:

  • Before an order is broadcast, a market maker privately sends the order and an anti-spam fee transaction to a  Service Node, which can broadcast the latter, spending the coins as a network fee and costing the maker money  if it act maliciously. Upon validation of the fee transaction, the Service Node signs the order, which would-be  market takers use to validate the order.
  • When an order is broadcast, traders may verify, on their own, that (a) the order is backed by real coins, and (b)  that it has been signed by a Service Node (signifying that a trade fee has been paid).
  • When one or more traders attempt to accept an order, the market-maker adjudicates between these requests  (standardly accepting the first valid request) and, on its own, selects its counterparty.
  • When a counterparty is selected, it is in the maker’s interest that the counterparty will not DOS the trade, and so  it awaits verification by a Service Node that a trade fee was paid.
  • Once a Service Node broadcasts a signed acceptance-message, the rest of the market updates its order books by  removing the order from the book.

As such, Block DX’s order book functions as a decentralized state machine. The following diagram represents the state  machine at a high level (the sections that follows introduce certain details in the diagram):

Separation Of Roles: Service Nodes

The Blocknet’s order system is a three-party system, rather than simply being between the two counterparties to a trade,  and this is perhaps surprising. However, it comes as the result of considering the impact to the users experience of  precisely when a fee is charged. For example, it would be possible to implement a simple decentralized fee solution if  users were required to pay a trade fee prior to placing an order, yet this would result in their being charged even if they  were to cancel an order, and even if their counterparty were to abandon a trade. In order to obtain the desired behaviour  (that is, for users to only be charged a trade fee if the trade completes or if they cancel), yet simultaneously for fees to be  paid upfront, prior to placing an order, a three-party system is implemented. It is the result of separating the incentives to  offer liquidity, to take liquidity, to check that one’s counterparty has paid a fee, and to earn trade fees without (a) being  tempted to broadcast a trade fee transaction maliciously while (b) not charging trade fees unless an order is accepted.  Again, the overriding intention is self-sovereignty, and this is preserved by separating and aligning each party’s incentive  to behave in particular ways. This is a complex system, and for simplicity only a few considerations shall be discussed at a  time; at this stage in the discussion, the point is merely that Service Nodes are required to charge trade fees without  requiring them to be charged when a party cancels before an order is accepted (see the detailed protocol sketch above  for the exact roles and sequence in the order system).

Special Properties Of Service Nodes

To support a reliable mechanism for accepting but not spending trade fees (anti-spam and anti-DOS fees) if the party  cancels the order before it is accepted, Service Nodes have several novel properties.

  • 1.Limited in Number and Easily Identifiable
    Because trading counterparties rely on trade fees as an anti-spam and anti-DOS measure, it is necessary for  them to easily identify whether a fee was paid, and this requires to the ability to differentiate orders (and  order-acceptance messages) signed by a Service Node from other nodes’ signatures. To achieve this, we require Service Nodes to hold 5000 BLOCK. That way, any trader may easily scan the  blockchain for 5000 block UTXOS and compile a list of Service Nodes. Then, if one address containing 5000  BLOCK validates an order’s signature, it has been signed by a Service Node.
  • 2.Expensive to Act Maliciously
    Service Nodes shall be required to hold BLOCK for at least 1000 blocks before they may begin earning trade fees  and block rewards. If a Service Node acts maliciously – that is, by broadcasting a trade fee when a user cancels  an order legitimately – then the trader involved may submit a blacklist proof-claim to the network about the  Service Node. To escape the blacklist, the BLOCK would need to be moved to a new address, in which case the  Service Node would lose out on very many trade fees and block rewards while waiting 1000 blocks.
  • 3.No Profit from Acting Maliciously
    In addition to the high opportunity cost of acting maliciously, a Service Node cannot directly or predictably profit  from illicitly spending a trade fee, because trade fees are awarded to the next winning staker, which occurs  probabilistically and is thus indeterminate with respect to the winner. As such, Service Nodes have no practical  profit motive to act maliciously.
  • 4.Supportive of Cryptocurrencies and Tokens Interoperable with the Blocknet
    To validate an order or order acceptance message, Service Nodes are required to verify that the address(es) in  the order contain enough coins to fund the order. As such, they have significant hardware requirements, as they  are required to maintain full node wallets of each blockchain interoperable with the Blocknet. This requirement  further equips Service Nodes to relay messages and transactions for SPV and light nodes where necessary.
  • 5. No Opportunity to Practice Insider Trading

    Because any Service Node may sign orders, it is not practicable for a Service Node owner to privilege the orders  of any one trader (for  example, her own trading node), because if it delays signing the orders (or  order-acceptance messages) of others, they may trivially obtain good service from any other Service Node.

As a result of the above properties, traders have (a) a “good reason” to trust the testimony of a Service Node, (b) the  ability to inflict income-loss upon a Service Node in the event that it does not act truthfully, of an order of magnitude  greater than the loss of a trading fee. (c) As observed above, the low level of risk that traders are exposed to during an  order process, and the severe performance penalty that would be imposed to obtain a higher degree of certitude, does  not warrant their obtaining a higher degree of certitude about orders.

Order Matching System

The Blocknet requires a decentralized system for (a) translating standard order-types on exchanges (market, limit, etc)  into basic liquidity-consumption events, and (b) for matching quantities of one coin with quantities of another coin at  specified prices. Adopting the decentralized order state machine presented above – that is, where parties adopt  self-sovereign roles as either maker or taker – order matching consists of takers requesting to consume liquidity from  makers, and in the case of limit orders, the presence of absence of orders up to a certain threshold functioning to  determine the trader’s role as a maker or taker.

The behaviour of a market order is as follows: consume orders on the book, beginning from the best-priced order,  moving to the next-best-priced, and so forth, until the market order is completely consumed. If the market order  consumes all orders on the order book without being completely consumed, then cancel the remaining amount on the  order.

The behaviour of a limit order is as follows: if the order is a sell and the price of the order is lower (or if it is a buy and the  price of the order is higher) than the highest (lowest) counteroffer on the order book, then consume orders on the book

until either the user's order becomes the lowest (highest) offer, or is completely consumed. If the former, then add the  remainder of the trader's order to the order book.

To avoid issues with change on UTXO-based cryptocurrencies – and the resulting need to wait for the change to confirm  before the rest of an order can be traded – XBridge shall automate the distribution of trading wallets’ coins into small,  regular amounts at separate addresses, in order to maximise the number of outputs that are completely consumed by a  counterparty and minimise change to trivial levels. Additionally, a minimum trade size shall be imposed that corresponds  to the size of the amounts per address, to prevent the malicious creation of change.

Trade History Service

A history of trades between coins is required for charting and other technical analysis tools, and in general for traders to  obtain information about a market upon which to make trading decisions. The truthfulness of a trade history is of  paramount importance, because considerable advantage over other traders may be gained if one were to fabricate it. As  such, the trade history of any given currency pair shall be provided in a “trustless” manner as a Blocknet service.

The solution sketch that follows is somewhat idealised, for reasons of simplicity and in order to present the leading idea  rather than the detailed technical solution; a production-ready solution would be considerably more succinct (mostly due  to not including the trade history data itself in one of the the atomic swap transactions), and instead would employ a  more sophisticated zero-knowledge proof scheme like, for example, bulletproofs.

A “trustless” dataset would require (a) a suitably truthful means of committing trade history data to it, and (b) an equally  truthful means of retrieving data from it. The solution is as follows:

A trade history blockchain would be created, and its nodes’ work in establishing consensus would amount to committing  trade transaction data from other blockchains to the trade history blockchain. Typical data committed would include:

  • coin A
  • coin B
  • quantity of coin A
  • quantity of coin B
  • price of coin A : coin B
  • time that the first bail-in tx was spent

The data committed must be sufficient for consumers of the data to synthesise into many forms. For example for  TradingView charts, the following data would be required:

  • period of candle
  • start time of candle
  • open price
  • close price
  • high
  • low
  • and so forth

Commitment Proof Data To commit trade data, nodes on the trade history blockchain must submit proof data:

  • coin A
  • coin B
  • txid of spent bail-in transaction on chain A
  • txid of spent bail-in transaction on chain B (or mark if absent)
  • txid of spent trade fee transaction for market maker
  • txid of spent trade fee transaction for market taker
  • timestamps of all transactions
  • timestamp for the transaction in which the proof data is submitted

Proof data submitted by a node is then verified by the network by searching the blockchains of the coins involved in a  trade and validating the proof data against the the coins’ blockchains. Nodes would also engage in a deduplication  exercise similar to mining with respect to the fact that the network must determine the first node to submit proof data  for a given trade, and discard proof data submitted by other nodes.

Data Retrieval Methods

  • ・download the trade history blockchain, and thus retrieve the data for free
  • ・store in local memory all completed trades – which would require running Block DX continually (in practice, this  would only be useful for updating a chart in realtime)
  • ・request trade history from a node on the trade history chain, for a fee:
      ・for a specified coin pair
      ・over a specified time

Supply of Trade History Data

To supply trade history to traders, nodes on the trade history blockchain must submit:

  • a hash of all txids for coin A, coin B, and trade fees within the time range specified by the trader
  • the node’s address

With this data, the trader constructs a simple zero-knowledge proof (though see the note above) of the truthfulness of  the data by requesting trade history from many nodes on the trade history blockchain, and verifying that the supplied  hashes are identical. If the results are identical, then this amounts to a low probability that the data is untruthful, because  the nodes have no good reason to trust one another and are thus not in a strong position to collude maliciously. If the  trader wishes to obtain greater certainty about the truthfulness of the data (s)he may request trade history from mode  nodes, or download the blockchain herself. Nodes may further monitor each others’ responses to traders and punish  dishonest nodes by submitting proofs of how their response is unfaithful to the record in the blockchain; on this basis it  is trivial for the network to reach consensus about the dishonesty of a node and blacklist it.

If the trader is satisfied with the response(s) from the trade history nodes, it would pick the first node to supply the  hashes, and commence an atomic swap with the following properties:

  • ・a bail-in transaction only spendable using
      ・a private key corresponding to the address the node provided, and
      ・the trade history data corresponding to the hash provided
  • ・(In other words, the trade history data functions as the secret in the atomic swap)

As such, if the trade history node spends the bail-in transaction, then it must reveal the trade history data, and so the  trader receives it. Simultaneously, the trade history data cannot be revealed without the trader paying for it.

The current (and simplistic) sketch has a few properties worth noting:

  • The size of the requested dataset may be limited by the maximum field length for the secret in the transaction  format. This, then, drives revenue for trade history nodes by requiring traders to submit more than one request  if they desire trade data over a longer timeframe.
  • The fee per dataset may be dynamically adjusted against the trade volume, since greater volume per unit time  would reduce the time span of a dataset of a certain maximum size.
  • Mild obfuscation of trade history data is provided against other traders intercepting the requested trade history  data once the trade history node reveals it: because they neither the trading pair nor the timeframe is included  in the dataset, it will not be obviously useful to them and would be expensive and complex to synthesise.
  • Strong obfuscation of trade history data would be afforded by it being sent encrypted over XChat, and the secret  in the atomic swap functioning also as a decryption key for the data. This, however, would require a more  sophisticated zero-knowledge proof that the one in this sketch (see above).

Registry Service

The trade history service above appears to be generalisable to provide a workable registry service for inter-chain services.  Intuitively, where the trade is not for a coin but for a digital good instead, the commit and lookup phases in blockchain  routing remain unchanged. What would be required in addition is for trade history nodes to filter their blockchain’s  record of trades for the most recent record in which a chainId appears, and to compile the resulting list of chainIds and  their associated serviceIDs. This list would be delivered, instead of trade history, using the protocol in the preceding  section.

Project Phases

The following section is a broad outline of the long term course of the project, intended for gauging overall scope, and is  not a series of commitments to development milestones. Shorter-term roadmaps, with well-defined milestones, are  published as necessary.

PRODUCTION MVP

  • Monolithic client/node
  • Decentralized exchange dapp

PHASE 2

  • Modularise xbridgep2p
  • APIs for all modular components
  • Support for data payload in exchange protocol
  • Easy interoperability between exchange protocol and xchat transport protocol (controlled via your own Dapp)

PHASE 3

  • Support for further order types: trailing stop, OCO
  • Support for leaving orders in book after closing app (orders committed to blockchain)

PHASE 4

  • Protocol enhancement: derivative market for swaps (p2p margin lending)
  • Protocol enhancement: generic derivative markets

Technical Specification

For easier maintenance, and in order to retain a single source of truth for low-level documentation, this section has been  moved to GitHub.

MESSAGE SEQUENCES

Forthcoming. See https://github.com/BlocknetDX/blocknet-docs

API REFERENCE

See https://github.com/BlocknetDX/BlockDX/blob/master/doc/dx/dxapi.md

Use-Cases

Infrastructure for a not-yet-existing ecosystem presents some difficulties to the imagination. “What is this for?” is the  single most common design-focused question asked, and the correct answer is something like “anything that can benefit  from a token ecosystem” – which is most things. For a less abstract answer, here is a short list of use-cases for the  Blocknet:

1.Decentralized Exchange

The decentralized exchange of crypto-tokens is in fact a core service of the Blocknet, since it is necessary for the  monetisation of any other service.

This, within an easy-to-use dapp UI, is also the Blocknet’s first consumer product, since it fulfils a real need in the  crypto-community for decentralized trading technology.

The prevalence of hacks, fraud, failure, and theft from centralized crypto exchanges has resulted in an alarming  1 in 16 Bitcoins being stolen. A workable decentralized exchange will thus provide a vital enabling function in the  fledgling token ecosystem for the safe, secure exchange of coins and tokens

2.Blockchain Router

Blockchain routing is also a core service of the Blocknet, since inter-chain traffic must be routable to its intended  destinations. That said, it is also consumable as a valuable service, which any node may require in order to either  deliver or consume an inter-chain service. The Blocknet’s incipient router, XBridge, currently delivers a free  service, and this may remain so for the indefinite future.

3.Inter-Chain Messaging

Whether used as a chat app or as a data transport, inter-chain messaging is an indispensable service for the  token ecosystem. As with decentralized exchange and blockchain routing, this is a core Blocknet service, and it  goes by the name of “XChat.” It is end-to-end encrypted, peer-to-peer, and may be used for the ultra-secure  delivery of digital goods and messages. It is currently a free service, and is (currently) packaged alongside the  blockchain router in XBridge.

4.Mobile App Exploiting Multiple Chains

A mobile app, with its small footprint, would most likely have only one SPV node and its native blockchain token.  As such,

  • It would consume services, not other coins
  • Various blockchain services it consumes shall run Blocknet components
  • When the app requests a service, the service shall generate a “secret” which is also a decryption key for  the digital goods
  • The service shall send data enabling the app to construct a zero-knowledge proof that the goods are  legitimate
  • The service shall create a bail-in transaction in an atomic swap
  • The service shall spend the bail-in transaction and later trade it for another coin, if preferred
  • The app thus receives the secret and may consumes the service

5.Near-Perfect Coin Mixer

A private currency such a ZCash, ZCoin, or Monero may integrate to XBridge, and script the automatic trading of  any currency for the private currency and back again into the original currency. Since the decentralized exchange  does not require any third party to be trusted with users’ data, and since the atomic swap involves no  counterparty risk, the result is a nearly perfectly private mixing service.

6.Decentralized Marketplace Spp

A marketplace app would typically require the following services: (a) customer reputation and info, (b) payment  processing, (c) image storage, (d) item listings. A microservices architecture is advisable for the reasons given  above, gaining the advantages of utilising multiple blockchains. Thus, one chain may store encrypted customer  info (see item 13 on this list), use the XBridge to accept payments in any cryptocurrency, store images on a  server, and use a third chain and in-wallet code for the item listings and UI elements. The result is a scalable,  composable set of services that are easier to bugfix, upgrade, or replace.

7.Fuel-Converter for Ethereum Smart Contracts

Using the decentralized exchange, any Ethereum contract may be supplied with "gas" in other coins.

8.Truly Decentralized Stablecoin

A stablecoin may maintain its peg by exploiting the fact that trade records on a decentralized exchange are  on-chain. As such, a provably truthful dataset is available for determining whether to mint or burn coins (or  freeze and unfreeze them) in order to maintain a peg.

9.Self-Sovereign ID and Personal Information Manager

A personal information service may records encrypted personal metadata on a given blockchain equipped with a  revocable permissioning system. Users thus acquire self-sovereignty over their personal information. From this  point, one may integrate this blockchain to any website or app requiring sign-in, or users can voluntarily sell their  metadata to advertisers for micropayments, or it can support passport/identity systems. Emerging technologies  positioned to exploit this use case are Bitnation and Microsoft’s Coco Framework.

10.Supply Chain 2.0 Solution

Blocknet infrastructure is well-suited to function as a “supply chain 2.0” backbone. Parties typically find  themselves on different blockchains, with a need to interoperate, and may do so by exploiting Blocknet services.  Multichain apps will thus be able to read data from several chains, whether they are specialized in shipping data  like Bill of Lading, product manufacturing data like Bill of Material, financial dat, and so forth. By comparing  metadata from several sources, the Blocknet could empower companies to limit attack vectors like invoice  spoofing and certification counterfeiting.

11.IoT Infrastructure

Some perennial IoT security issues may be solved by exploiting blockchain technology, and then interoperating  between thousands of blockchains over the Blocknet. Diverse opportunities for granular monetisation present  themselves too: for example, one may accomplish transaction batching on several chains at once using SPV  wallets. The data stream may thus be tokenized, and nodes may be incentivised to engage in pattern finding in a  company’s big data.

12.In-App Ad Service

A mobile app may earns its users tokens by screening ads delivered to the app as a Blocknet service. Tokens  could then be used to power inter-chain service consumption for the app, delivering a “free” service for the user,  but a monetised one for the service providers.

13.Decentralized p2p Storage Solution

A blockchain-based storage solution, such a Storj, may have its user base significantly enlarged and monetized  via inter-chain service delivery.

14.Permissionless ICO Platform

Anyone may offer token sale over a decentralized exchange, with no permission required.

15.Business Case Tool for Distributed Budget Management

Crypto projects are typically launched as a big crowdsourced business case (ICO), where a budget is negotiated  with the market. However, the actual account balance fluctuates as the price of the cryptocurrency the  crowdsourcing was conducted in. changes in value. Using the Blocknet, developers may manage the distribution  of tokens and accounts across chains. Furthermore, with the use of a smart contract, disbursements and  investments in other coins may be managed and, in general, the project’s business plan coded and automatically  executed by the contract with perfect transparency.

16.Integration to ERP, CRM, PLM Systems Across Companies

The Blocknet’s simple API-based integration enables interoperability either directly or indirectly with  consortium-type and private blockchains, like those of ORACLE and SAP.

17.Infrastructure for the Internet of Value

The Blocknet’s inter-chain infrastructure shall function increasingly over time to create an “internet of value” that  is inherently truthful, transparent, and fairly available. As companies’ general- and sub-ledgers come gradually to  interface with other companies’ ledgers through blockchains, the resulting network of blockchains will become a  full representation of value streams and of a given system’s value. This enables advanced and deep awareness of  value across entire systems, with correspondingly powerful and far-reaching consequences for the financial  system.


これにて本文は終わりです

BlockNet (BLOCK)に関連する他の情報に触れてみる

PocketWPについて

暗号資産(暗号通貨, 仮想通貨)やブロックチェーンは理解が難しく、また一次情報の多くはPCに最適化されている状況にあります。PocketWPでは、下記の3点のアプローチによってその問題を解決しようとしています。
  • ・SmartPhoneFirst - スマホで最適化したスライド/UI
  • ・Stockable - 流れてしまいがちな情報を蓄積し、共有できる
  • ・Followable - 追いかけるべき情報源がわかる
将来的には共同で編集できる仕組みなども設計中です。 暗号資産・暗号通貨の価値を広げるには、良質な情報を読みやすく噛み砕くことが必要だと思っています。 よろしければご意見をこちらからお寄せください (お問い合わせフォーム)
運営者情報① : IXTgorilla
IXTゴリラ
@IXTgorilla
Twitterにて #PocketWP #ゴリ学習メモ なるスマホに最適化した暗号資産の学習情報をスライド形式にて発信しているゴリラ。 これまではTwitterのみの発信を行なっていましたが、蓄積される場所が欲しいという声にお答えし、Web化を行なってみました。
運営者情報② : CryptoGorillaz
暗号通貨に関する情報を共有するコミュニティ。当初はコラ画像などをつくる集団だったが、暗号通貨の魅力や将来性にほだされ、日夜暗号通貨に関する情報共有を行なっている。(IXTゴリラもここに所属しています)

寄付/投げ銭はこちら

  • Ethereum(ETH) / ERC20トークンでの投げ銭
    0x77535cb08CF5Ba3B85A34A3B037766103226c783

森のお友達をご紹介 - PocketWPのオススメ

ゴリラが尊敬する森のお友達をご紹介するコーナー。 個人的に定期的に購読していただきたい!と思うメディアや事業者さまを勝手に紹介させていただいております。
StirLab | クリプト・ブロックチェーンを「深く」知る
StirLab
https://lab.stir.network/
クリプトアセット(仮想通貨・暗号通貨)に造詣が深い方々による寄稿型メディア「StirLab」。 クリプトが「好き」でその発展を純粋に「楽しむ」人たちが集まっており、ハイクオリティな記事が集まっています。 今話題のDeFiからSTOまでトピックは幅広く、知見を深めたい人にぜひとも定期的購読していただきたいサイトです。
StirLabさんのTwitterアカウントはこちら▶️ https://twitter.com/Stir_Lab
Stir | PoS系クリプトアセットのノード事業者
Stir
https://stir.network/
Tezos, Enigma, Cosmos, Ethereum, NEMといったPoS系クリプトアセットのマイニングやノード運用を代行する事業者。ブロックチェーン機構メディアで有名な「StirLab」の運営母体でもあります。
StirさんのTwitterアカウントはこちら▶️ https://twitter.com/stir_network