Lens, Gateway 등 조회 컨트렉트를 만들 때의 유의점

상황 : nft의 홀더리스트 조회를 백엔드 작업 없이 정확하게 리턴하도록 nftFactory에서 리스트를 가져와서 nft 주소를 입력하면 누가 어떤 tokenID를 가지고 있는지 구현한 상황

문제 : 한 홀더당 가지고 있는 nft의 수가 6500개가 넘어가면 (조회함수에서 리턴하는 배열에 6500개 이상의 데이터가 들어갈 시) 오류 발생, 여러 컨트렉트 동시 조회 시에는 이중 배열을 사용하여 100개가 넘는 종류의 nft를 가지고 잇을시 오류 발생.

요약 : 조회함수를 쓰더라도 몇개의 데이터까지 다룰 수 있는지 테스트 필요. 조회 함수더라도 네트워크에 따라서 연산 가능한 양과 인출 가능한 데이터가 다르며 생각보다 그 값은 크지 않음.

해결 방안 : 유저리스트, nft정보 조회를 조회 컨트렉트로 따로 파서 만들 시에는 페이징 함수를 추가하거나 아니면 컨트렉트 단에서 조회함수를 가져온 후 백엔드에서 멀티콜을 써서 따로 구현을 하는 것이 가장 좋음.

활용 방안 :  백엔드가 따로 있더라도 페이징을 넣어서 검산용으로 조회 컨트렉트를 사용하면 좋을 것으로 예상. 실시간성을 강하게 요구하거나 복잡한 컨트렉트 계산이라면 컨트렉트에서 페이징 기능을 넣은 후에 백엔드에서 페이징을 해주는 로직을 만들도록 구현가능. 다만 현재의 상황에서는 단순히 특정 계정이 들고있는 nft리스트를 뽑아내는 것이였기에 백엔드 로직이 더 간단하다고 판단.

컨트렉트 조회 함수 부하 테스트 시 사용한 batch Mint에 대한 병렬 처리 로직

        async function parallelMint(accountAddress: string, batches: number, mintsPerBatch: number) {
          let promises = [];
      
          for (let i = 0; i < batches; i++) {
              const promise = ContractName.batchMint(accountAddress, mintsPerBatch)
              .then(tx => console.log(`Batch ${i + 1}: Transaction sent with hash ${tx.hash}`))
              .catch(error => console.error(`Batch ${i + 1}: Error minting - ${error.message}`));
              promises.push(promise);
          }
      
              // Wait for all the promises to resolve
              await Promise.all(promises);
              console.log('All minting transactions have been sent.');
        }
        
        await parallelMint(account1.address, 20, 250);

* 부하테스트시에는 Promise.all을 안쓰면 너무 시간이 오래걸리므로 사용하여 실행.