체인의정석

폴리곤의 pos 브릿지에서는 토큰의 타입등과 같이 이벤트로 남기는 값에 있어서 주소값을 제외하고는 bytes32를 남긴다. 이에 대해 찾아보니 bytes32는 일반 byte에 비하여 용량을 적게 사용한다고 한다. 가스비를 최대한 줄여야 하기 때문에 bytes32를 자주 쓰는것으로 보인다. 다음은 이더리움에 있는 테더의 주소이다. https://etherscan.io/address/0xdAC17F958D2ee523a2206206994597C13D831ec7#code Tether: USDT Stablecoin | 0xdAC17F958D2ee523a2206206994597C13D831ec7 The Contract Address 0xdAC17F958D2ee523a2206206994597C13D831ec7 pag..

상속관계를 최대한 가볍게 하기 위하여 인터페이스 부분에 mapping을 넣어 놨었는데 메핑처럼 변수들은 인터페이스에서 정의가 되면 안된다. 인터페이스에서 정의되는 것은 함수 또는 이벤트여야 한다. 이를 지키지 않을 경우 TypeError: Variables cannot be declared in interfaces. 와 같은 컴파일 에러가 나게 된다. 따라서 메핑을 불러와서 조회에 쓰는 경우에는 조회를 하는 함수를 external로 인터페이스에서 만들어서 보여주는 것이 맞다. 메핑 자체를 public으로 보여주지 않고 내부적으로만 접근 가능하게 해놓고 external로 해두는 이유가 이렇게 인터페이스화를 하여 상속을 하여 상속 관계를 깔끔하게 정리해주기 위함이 아닌가 하는 생각이든다. 아무튼 오류 해결을..

인터페이스의 경우 결국 외부에서 호출해와서 external call을 해야하는 것이기 때문에 public은 제외하고 external만 정의해야 한다. https://github.com/ethereum/ethereum-org/issues/809 Functions in interfaces should be declared external. TokenERC20 Contract · Issue #809 · ethereum/ethereum-org Hi, I am receiving the following error when using the TokenERC20: interface tokenRecipient { function receiveApproval(address _from, uint256 _value, add..

이벤트를 작성하면서 어차피 가스비가 많이 들지 않으니 활용을 위해 인덱스를 최대한 많이 넣어보자 라는 생각으로 많은 인덱스를 달아 보았다. 그 결과 TypeError: More than 3 indexed arguments for event. 와 같은 오류가 나왓다. 사실 인덱스를 이렇게 달아본건 처음이라 여기에 제한이 있었나? 하고 찾아보니 https://ethereum.stackexchange.com/questions/52397/im-getting-an-error-when-i-have-more-than-3-indexed-arg-for-an-event I'm getting an error when i have more than 3 indexed arg for an event I want to add al..

Solidity 에서는 input값을 스토리지가 아닌 memory에 넣는다. string, bytes, struct에서는 이러한 표시를 해주지 않으면 컴파일 에러가 나게 된다. 다만 0.5.0 버전의 external에서는 솔리디티 컴파일러가 external 함수의 파라미터로 memory를 받지 않는다. Note that external functions require parameters with a data location of calldata. 그 이유는 external 함수가 아니라면 내부적으로만 호출되므로 calldata를 사용할 일이 없기 때문이다. 따라서 external의 인자값에는 memory가 아닌 calldata를 사용한다. 참고 : https://ethereum.stackexchange...

컨트렉트를 작성하고 컴파일을 하면서 TypeError: Linearization of inheritance graph impossible 다음과 같은 에러가 나타났다. 이러한 에러에 대하여 찾아보니. 상속의 순서를 최소화 시키지 않고 중복되지 않게 해야 오류가 안난다고 한다. 이에 따라서 확장성을 고려하여 설계한 각 컨트렉트에서는 하나의 인터페이스로 묶고 인터페이스를 상속해주어야지 실제로 해당 하위 컨트렉트에 external을 불러와서 사용할 수 있게 되기 때문에 원래 작성했던 컨트렉트에서 공통된 부분으로 뽑아서 하위에 전달해야 하는 공통부분을 인터페이스로 만드는 작업을 진행하였다. 각 토큰 유형별로 있는 컨트렉트의 공통 함수를 뽑아서 하나의 인터페이스로 잡은 후 최상단에서는 해당 인터페이스만 작업하도록..

Require과 Assert를 사용하는 방법 1. 함수가 실패해야 할 경우 실패를 하게 만든다. 2. 배후에 실행되는 것을 확실하게 하기 위하여 이전에는 실행이 되지 않게 require를 사용해야 한다. 3. 자신이나, 테스터에게 함수가 실패할 수 있을 경우를 상기시키기 위하여 사용한다. require 형태의 실패를 유발하기 위하여 DRY를 지키는 것이 중요하다. 그리고 해피케이스의 최소 조건에서 멀어진 단위테스트를 하면 fail이 일어나게 한다. 또한 각 함수의 유니크한 require 메세지를 통하여 왜 실패하였는지를 밝히는 것이 중요하다. 테스트 Modifier에 대하여 require 체크와 유사하게 모든 modifier들은 테스트를 해야 한다. 예를 들어 submitProposal 단위 테스트는 o..

이제 배포를 했으니 테스트코드를 작성하고 돌려봐야 한다. 테스트 코드는 딱히 가나슈랑 다른 점은 없어보여서 그대로 가져와서 사용해보기로하였다. const { expect } = require("chai"); const { ethers } = require("hardhat"); describe("Greeter", function () { it("Should return the new greeting once it's changed", async function () { const Greeter = await ethers.getContractFactory("Greeter"); const greeter = await Greeter.deploy("Hello, world!"); await greeter.deplo..