체인의정석

이더리움 value의 경우 숫자가 커서 빅넘버처리를 안해주면 에러가 나게 된다. 단위가 너무 크기 때문인데 조사해본 결과 빅넘버 처리는 결과 목적에 맞는 모듈을 사용하는것이 정답이라고 한다. 타입스크립트도 사용하였으니 한번 유명한 ether.js를 찾아보았다. 처음 써보는데 너무 편리했다. 일단 ether.js 에서 사용하는 bignumber의 경우에는 elliptic로직에서 쓰이는것과 같은 방법이기 때문에 가장 안전하다고 한다. 오랜기간 서칭을 한 결과 몇가지 케이스에 대한 방안을 알 수 있었다. 1. 이더리움 단위로 만들 경우 //ethers.utils.formatEther( value ) ⇒ string const value = BigNumber.from("1000000000000000000"); ..

입력값을 수정하는 부분이 nest.js에서 매우 중요한데, 사실 이게 타입스크립트를 쓰는 이유이기도 한다. 타입스크립트를 사용하게 되면, 타입을 모두 지정해 줄 수 있어서 모든 request , response 그리고 그 안에 들어가는 요소들을 객체화 시키고 타입을 지정하여 모든 상황에 대한 예외를 잘 잡아 줄 수 있다. 1. Class validator 사용의 경우 이번 프로젝트를 구현하면서 가장 많이 사용한 것은 class-validator 이다. Validation Pipe 모듈의 경우 클래스 형태로 요청을 받아줄 때 사용가능하기 때문에 일반적인 string의 형태나 단일 타입에 적용 시킬 수는 없다. 따라서 조회를 쿼리 파라미터로 실행하는 경우 class-validator를 실행한다고 보면 된다...

1. 공통 예외처리 부분 에러 처리의 경우 결과적으로 invalid input과 internal server error로 나뉘었다. 여기에 대한 구조는 다음과 같다. @Get('/:ethAddress/경로') async 함수이름( @Param('ethAddress') ethAddress: string, . . . @Query('page') page?: number, ): Promise { //오류의 경우 공통 부분으로 빼두어서 관리 const 객체화된요청 = new RelatedTransactionsRequest( ethAddress, new Date(fromDate), . . page * 1, ); const errors = await validate(객체화된요청); //쿼리 파라미터가 있는 경우 va..

노드 버전을 높이고 나서 npm install을 하다가 갑자기 다음 에러가 떴다. npm ERR! git@github.com: Permission denied (publickey). npm ERR! fatal: 리모트 저장소에서 읽을 수 없습니다 npm ERR! npm ERR! 올바른 접근 권한이 있는지, 그리고 저장소가 있는지 npm ERR! 확인하십시오. vs 코드를 껐다켜도 보니 에러가 많이 줄어있어 컴퓨터도 재시작해봤지만 효과가 없었다. 이런 경우 깃허브의 접근 문제인데 1. 회사에서 쓰는 모듈에 접근 권한이 없는 경우 이 경우는 깃허브에 들어가서 코드를 볼 수있으면 권한이 있는것이니 패스했다. 2. vs코드에서 깃허브 로그인이 풀린경우 이번엔 2번의 케이스 같아 다음과 같은 병령어로 현재 접속된..

Nest.js에서 여태까지 class validator를 사용하기 위하여 constructor를 사용하여 모든 클래스를 생성한 하여 valditaion을 진행하였다. 하지만 validation Pipe를 사용하면 이러한 과정을 모듈로 깔끔하게 할 수 있다는 사실을 알게 되어서 적용해 보려고 한다. 이걸 잘 사용하면 중복된 코드를 대량으로 줄일 수 있을것 같다. 우선 constructor 부분이 삭제가 되면서 1차적으로 코드가 깔끔해지며, 2차적으로 공통 모듈로서 validation하는 부분을 설정해 줌으로서 더 클린하고 유지보수가 쉬운 코드가 나오게 될 것으로 기대하고 리팩토링을 진행하도록 하겠다. 먼저, validation Pipe의 경우 nest.js 공식 document에 있기 때문에 이를 정독해보..

현재 진행중인 프로젝트는 장기 프로젝트로 url을 작성할 때 확장성이 있게 만들어야 한다. 아래와 같이 원래의 경로에 중간에 쿼리 파라미터가 들어가게 될 경우 시스템이 인식하기로는 파라미터에 ethAddress가 들어가던지 btcAddress가 들어가던지 같은 값으로 인지하게 된다. 따라서 아래의 코드와 같이 확장성을 고려한 경로를 만드려면 쿼리 파라미터의 변수 이름을 바꾸는 것은 아무런 의미가 없고 경로를 하나씩 더 추가하여 만들어야 한다. 장기 프로젝트의 경우 맨 처음부터 확장성을 고려하여 아래와 같이 예상되는 기능별로 경로를 최대한 구조 수정 없이 변경이 가능하도록 사전작업을 해두는것이 유리한다고 본다. /addresses/${ethAddress}/... //원래의 경로 /addresses/eth/..

Minting Assets Pre requisite 1 - 먼저 화이트리스트를 신청 후 인터페이스 상속시키기 - Proxy Contract에 트랜잭션을 보냄 Pre requisite 2 - Mintable CA - API URL - Meta data - Owner Pub Key deployed contract => 주소가 아닌 진짜 pubKey Pre requisite 3 - User registration 1. 토큰 민팅 { "mints": [{ "user": "0x...", "tokens": [{ "type": "ERC721", "data": { "id": "", // custom asset ID (it's possible to make this the ERC-721 token ID depending..

출저 : https://docs.x.immutable.com/docs/concepts Immutable X Concepts There are three core components to the Immutable X stack: the ZK-Rollup scaling engine, Link and the APIs. These components work together to lower the barriers of entry in the NFT space for developers and users, and enable instant trade confirmation, massi docs.x.immutable.com 이번 글은 제대로 된 정리본을 만들기 위한 사전 조사 수준의 자료 정리로, 간단한 해석 수준..