You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

133 lines
5.6 KiB

7 years ago
7 years ago
  1. Application Architecture Guide
  2. ==============================
  3. Overview
  4. --------
  5. A blockchain application is more than the consensus engine and the
  6. transaction logic (eg. smart contracts, business logic) as implemented
  7. in the ABCI app. There are also (mobile, web, desktop) clients that will
  8. need to connect and make use of the app. We will assume for now that you
  9. have a well designed transactions and database model, but maybe this
  10. will be the topic of another article. This article is more interested in
  11. various ways of setting up the "plumbing" and connecting these pieces,
  12. and demonstrating some evolving best practices.
  13. Security
  14. --------
  15. A very important aspect when constructing a blockchain is security. The
  16. consensus model can be DoSed (no consensus possible) by corrupting 1/3
  17. of the validators and exploited (writing arbitrary blocks) by corrupting
  18. 2/3 of the validators. So, while the security is not that of the
  19. "weakest link", you should take care that the "average link" is
  20. sufficiently hardened.
  21. One big attack surface on the validators is the communication between
  22. the ABCI app and the tendermint core. This should be highly protected.
  23. Ideally, the app and the core are running on the same machine, so no
  24. external agent can target the communication channel. You can use unix
  25. sockets (with permissions preventing access from other users), or even
  26. compile the two apps into one binary if the ABCI app is also writen in
  27. go. If you are unable to do that due to language support, then the ABCI
  28. app should bind a TCP connection to localhost (127.0.0.1), which is less
  29. efficient and secure, but still not reachable from outside. If you must
  30. run the ABCI app and tendermint core on separate machines, make sure you
  31. have a secure communication channel (ssh tunnel?)
  32. Now assuming, you have linked together your app and the core securely,
  33. you must also make sure no one can get on the machine it is hosted on.
  34. At this point it is basic network security. Run on a secure operating
  35. system (SELinux?). Limit who has access to the machine (user accounts,
  36. but also where the physical machine is hosted). Turn off all services
  37. except for ssh, which should only be accessible by some well-guarded
  38. public/private key pairs (no password). And maybe even firewall off
  39. access to the ports used by the validators, so only known validators can
  40. connect.
  41. There was also a suggestion on slack from @jhon about compiling
  42. everything together with a unikernel for more security, such as
  43. `Mirage <https://mirage.io>`__ or
  44. `UNIK <https://github.com/emc-advanced-dev/unik>`__.
  45. Connecting your client to the blockchain
  46. ----------------------------------------
  47. Tendermint Core RPC
  48. ~~~~~~~~~~~~~~~~~~~
  49. The concept is that the ABCI app is completely hidden from the outside
  50. world and only communicated through a tested and secured `interface
  51. exposed by the tendermint core <./specification/rpc.html>`__. This interface
  52. exposes a lot of data on the block header and consensus process, which
  53. is quite useful for externally verifying the system. It also includes
  54. 3(!) methods to broadcast a transaction (propose it for the blockchain,
  55. and possibly await a response). And one method to query app-specific
  56. data from the ABCI application.
  57. Pros:
  58. - Server code already written
  59. - Access to block headers to validate merkle proofs (nice for light clients)
  60. - Basic read/write functionality is supported
  61. Cons:
  62. - Limited interface to app. All queries must be serialized into []byte (less expressive than JSON over HTTP) and there is no way to push data from ABCI app to the client (eg. notify me if account X receives a transaction)
  63. Custom ABCI server
  64. ~~~~~~~~~~~~~~~~~~
  65. This was proposed by @wolfposd on slack and demonstrated by
  66. `TMChat <https://github.com/wolfposd/TMChat>`__, a sample app. The
  67. concept is to write a custom server for your app (with typical REST
  68. API/websockets/etc for easy use by a mobile app). This custom server is
  69. in the same binary as the ABCI app and data store, so can easily react
  70. to complex events there that involve understanding the data format (send
  71. a message if my balance drops below 500). All "writes" sent to this
  72. server are proxied via websocket/JSON-RPC to tendermint core. When they
  73. come back as deliver\_tx over ABCI, they will be written to the data
  74. store. For "reads", we can do any queries we wish that are supported by
  75. our architecture, using any web technology that is useful. The general
  76. architecture is shown in the following diagram:
  77. .. figure:: assets/tm-application-example.png
  78. Pros:
  79. - Separates application logic from blockchain logic
  80. - Allows much richer, more flexible client-facing API
  81. - Allows pub-sub, watching certain fields, etc.
  82. Cons:
  83. - Access to ABCI app can be dangerous (be VERY careful not to write unless it comes from the validator node)
  84. - No direct access to the blockchain headers to verify tx
  85. - You must write your own API (but maybe that's a pro...)
  86. Hybrid solutions
  87. ~~~~~~~~~~~~~~~~
  88. Likely the least secure but most versatile. The client can access both
  89. the tendermint node for all blockchain info, as well as a custom app
  90. server, for complex queries and pub-sub on the abci app.
  91. Pros:
  92. - All from both above solutions
  93. Cons:
  94. - Even more complexity; even more attack vectors (less
  95. security)
  96. Scalability
  97. -----------
  98. Read replica using non-validating nodes? They could forward transactions
  99. to the validators (fewer connections, more security), and locally allow
  100. all queries in any of the above configurations. Thus, while
  101. transaction-processing speed is limited by the speed of the abci app and
  102. the number of validators, one should be able to scale our read
  103. performance to quite an extent (until the replication process drains too
  104. many resources from the validator nodes).