improve transaction confirmation performance from sharders

[cnlangzi]

gosdk/zcncore/transaction.go

Line 909 in 520f39c

confirmBlock, confirmation, lfb, err = getTransactionConfirmation(getMinShardersVerify(), t.txnHash)

go func() {
		for {
			// Get transaction confirmation from random sharder
			confirmBlock, confirmation, lfb, err := getTransactionConfirmation(1, t.txnHash)
			if err != nil {
				tn := int64(common.Now())
				Logger.Info(err, " now: ", tn, ", LFB creation time:", lfb.CreationDate)
				if util.MaxInt64(lfb.CreationDate, tn) < (t.txn.CreationDate + int64(defaultTxnExpirationSeconds)) {
					Logger.Info("falling back to ", getMinShardersVerify(), " of ", len(_config.chain.Sharders), " Sharders")
					confirmBlock, confirmation, lfb, err = getTransactionConfirmation(getMinShardersVerify(), t.txnHash)
				

A transaction is verified twice. But 2nd is same as 1st. It should be removed

gosdk/zcncore/transaction.go

Line 503 in 520f39c

numSharders = len(_config.chain.Sharders) // overwrite, use all

func getTransactionConfirmation(numSharders int, txnHash string) (*blockHeader, map[string]json.RawMessage, *blockHeader, error) {
	result := make(chan *util.GetResponse)
	defer close(result)

	numSharders = len(_config.chain.Sharders) // overwrite, use all
	queryFromSharders(numSharders, fmt.Sprintf("%v%v&content=lfb", TXN_VERIFY_URL, txnHash), result)
	maxConfirmation := int(0)
	txnConfirmations := make(map[string]int)

numSharders is overwritten by len(_config.chain.Sharders) .

They should be improved with min_confirmation and parallel requests like #195

[cnlangzi]

We need get next round from different sharder to confirm current transaction. see detail on

but there are corner cases like in the case of 1 or 2 sharders.

[cnlangzi]

Saswata Basu 5 minutes ago
I think there was an issue with random/different sharder because if sharder1 is down, it would take a long time to get a response. So the idea was to query more sharders at the same time

Saswata Basu 4 minutes ago
So change the UML flow to query multiple random sharders, and then repeat with multiple ones for next block (edited)

Saswata Basu 3 minutes ago
Because its random, the chances are with min_confirmation, different sharders will be selected and it covers the case for 1/2 sharders. this is simpler algorithm (edited)