0chain / gosdk

A client SDK in Go to interface the blockchain and storage platform, and other smart contracts
MIT License
32 stars 29 forks source link

improve transaction confirmation performance from sharders #214

Closed cnlangzi closed 2 years ago

cnlangzi commented 3 years ago

https://github.com/0chain/gosdk/blob/520f39c0fe70bd33a21c7eff1d269386ac653f86/zcncore/transaction.go#L909

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

https://github.com/0chain/gosdk/blob/520f39c0fe70bd33a21c7eff1d269386ac653f86/zcncore/transaction.go#L503

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 https://github.com/0chain/gosdk/issues/195

cnlangzi commented 3 years ago

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

light-client-validation

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

cnlangzi commented 3 years ago

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)