Hello,
for a University project, we're currently evaluating the possibility of using Multichain as a financial transaction journal engine, with the basic principle of representing each user account as an address in the wallet and using direct RPC calls to read and write information. With this central database approach in mind, we're thinking of running one node only as there's nothing we'd gain from the decentralisation, simply inside our cluster away from the public.
As part of a performance estimation, we tried setting up a chain to the best of our understanding, aiming to optimise as much for performance as possible:
chain-protocol = multichain
chain-description = MultiChain test-10k
root-stream-name = root
root-stream-open = true
chain-is-testnet = false
target-block-time = 2
maximum-block-size = 8388608
maximum-chunk-size = 1048576
maximum-chunk-count = 1024
anyone-can-connect = false
anyone-can-send = true
anyone-can-receive = true
anyone-can-receive-empty = true
anyone-can-create = false
anyone-can-issue = true
anyone-can-mine = false
anyone-can-activate = false
anyone-can-admin = false
support-miner-precheck = true
allow-arbitrary-outputs = false
allow-p2sh-outputs = false
allow-multisig-outputs = false
setup-first-blocks = 3
mining-diversity = 0.0
admin-consensus-upgrade = 0.0
admin-consensus-txfilter = 0.0
admin-consensus-admin = 0.0
admin-consensus-activate = 0.0
admin-consensus-mine = 0.0
admin-consensus-create = 0.0
admin-consensus-issue = 0.0
lock-admin-mine-rounds = 0
mining-requires-peers = true
mine-empty-rounds = 0
mining-turnover = 0.0
initial-block-reward = 0
first-block-reward = -1
reward-halving-interval = 52560000
reward-spendable-delay = 1
minimum-per-output = 0
maximum-per-output = 100000000000000
minimum-offchain-fee = 0
minimum-relay-fee = 0
native-currency-multiple = 100000000
skip-pow-check = true
pow-minimum-bits = 1
target-adjust-freq = -1
allow-min-difficulty-blocks = true
only-accept-std-txs = true
max-std-tx-size = 4194304
max-std-op-returns-count = 32
max-std-op-return-size = 2097152
max-std-op-drops-count = 5
max-std-element-size = 40000
default-network-port = 4771
default-rpc-port = 4770
chain-name = test-10k-fixed
protocol-version = 20012
network-message-start = f9f9cff0
address-pubkeyhash-version = 00330835
address-scripthash-version = 051c4624
private-key-version = 8013627a
address-checksum-value = 906c59f5
genesis-pubkey = 036b0f05c206bb7ac8e6bfd2869f473cf4b4acb0b94195944fe0371a2bfb3157f7
genesis-version = 1
genesis-timestamp = 1618841128
genesis-nbits = 536936447
genesis-nonce = 271
genesis-pubkey-hash = f0b759e6726332558339c7b7a8f6f8721e7927c5
genesis-hash = 00e08d153bf75996cfd758c6d09fd1fca23e7bb836fb47ea59ba15e473f381c5
chain-params-hash = b846252b96d6e3bc24b74eaaaa94163e3fe65584f1d1325992849054dfe07045
We then proceeded to create a total of one million addresses on the chain, using a custom golang script with 10 goroutine workers. This process took about 7 hours. Not stellar, but seeing as it would not be part of a burst phase and only needed for new user signups, it's acceptable.
We then proceeded to issue some different assets for each of the generated addresses using IssueMore (to simulate a user entering the ecosystem and having "paid in" to his account), also using a golang script. This process unfortunately is very slow. Each calls takes about 2 seconds. Since the IssueMore would only be used as a "user is paying in new currency" action, it also should not be that burstable, but 2 seconds on a completely empty chain sounds bad. It also prevents us from creating an equal distribution of currency among the addresses, as it would 2 million seconds per asset.
We have not yet proceeded to test the performance of sending assets between addresses. We were thinking of using SendAssetFrom to send currencies between different addresses - and sending to the burn address in order to simulate a user "cashing out" (with the currency leaving the ecosystem again)
Concrete questions
With the problem and data laid out above, I'd appreciate any feedback, especially regarding:
- Is Multichain a sensible choice for a centralised financial transaction database with high throughput?
- Are there any steps we can look at to further improve the current performance?
- Is there any data available on general scalability of Multichain?
We're happy to supply more information as required and thankful for any further insights.
Kind regards,
Peter
