How to solve the problem of amount accuracy in financial applications (take quorum and golang as examples)

Amount accuracy problem

background ： This paper focuses on the application of enterprise blockchain Quorum As an example （ The application is powered by golang To write ）, It explains how to solve the problem of amount accuracy .

The problem of amount accuracy is a problem that every financial system developer has to face , From the beginning of my career , From banking system , Internet payment company system , Until blockchain financial application , This problem is everywhere . The typical solutions to this typical problem are as follows .

Specific examples

ICBC account gold application （ Real applications ） The amount unit of is defined as float64, What problems will be caused in practice ？effective java Someone mentioned this problem , Will cause the following serious consequences （ I use golang Rewrite as follows ）：

package main

import "fmt"

const TEN_CENTS float64 = 0.1

func main() {

	var itemBought int = 0

	var myfund float64 = 1.00

	for price := TEN_CENTS; price < myfund; price += TEN_CENTS {

		itemBought++

		myfund -= price

		fmt.Println("loop")

	}

	fmt.Println(" What you buy ：", itemBought, "  Remaining amount ：", myfund)

}

If you use **“go run”** Command to run this file will have the following prompt output

[email protected]:~/gopath$ go run currency.go 

loop

loop

loop

 What you buy ： 3   Remaining amount ： 0.3999999999999999

Why? ？ Namely float64 In fact, it is not suitable for currency

The author of this question in the same series of blog 《 Ten questions about the safety of financial application fund processing 》 There is elaboration , See para 6 spot

---

that Quorum How to solve the problem ？

First , The expression of currency is international standard

Considering the different situations between countries , There are different forms of money , Will be in xml In the definition of

<currencies>
    <currency type="USD">
        <displayName>Dollar</displayName>
        <symbol>$</symbol>
    </currency>
    <currency type ="JPY">
        <displayName>Yen</displayName>
        <symbol>¥</symbol>
    </currency>
    <currency type="PTE">
        <displayName>Escudo</displayName>
        <symbol>$</symbol>
    </currency>
</currencies>

secondly , The smart thing to do is to avoid this problem , Like bitcoin , direct There is no decimal point , With Wei In units of , And it cannot be subdivided .

See the following code (core/types/transaction.go)

Amount       *big.Int        `json:"value"

So they all introduce math.big package , There is no decimal point

What about RMB ？

Define the form , For example, the smallest is a fraction , All the operations are unified and divided into two parts , And then calculate

The process is similar to the following ：

transformation – 》 Calculation – 》 transformation

---

The problem of currency accuracy has been solved in previous blockchain applications

• The currency Super precision ,38 position , Other things like Ethereum , It's all about taking math.bigInt,wei Is the smallest non subdivisible

• Fabric Is to build the bottom channel, Certificates and so on , There is no amount involved , This problem is thrown to the application layer

The debate on the route of bank application to amount processing ：

• International trade settlement application ： Set a special amount class , A signed , There are decimals , Yes complex Calculation rules

• Host core system application ： Only deal with RMB , So it's all set to points , Simplification rules

In the future, our application system , It is suggested that the first scheme be adopted , Internationalization is supported initially , As for the increased amount of calculation , In fact, the main performance bottleneck is not here