솔리디티 문해력 특강_ 1강
디사이퍼에서 진행한 솔리디티 문해력 특강을 개인적으로 기록으로 남기기 위해 정리한 글입니다.
해당 특강은 아래 링크에서 확인 가능합니다. 강의를 진행해주신 안수찬님께 감사드립니다.
안수찬님 블로그 : https://solidity.ansuchan.com/
디사이퍼 솔리디티 문해력 특강 유튜브 : https://www.youtube.com/playlist?list=PLOY0jYV3zWiElk6lAXhuyRJ8dMDqelU_r
첫번째 강의
다른 솔리디티 강의도 몇개 들어봤지만 솔리디티 문해력 수업은 중요한 내용이었고 깔끔한 좋은 강의였다.
컴파일되는과정 Hex로 변환되는 과정 그리고 검증하는 단계 까지 지금까지 알고있던 개념들이 하나씩 정리되는 내용이었다.
Blank contract
우리가 작성하는 컨트랙트가 하이레벨언어에서 어떻게 로우레벨 언어로 변하는지 확인 할 수 있었다.
→ Stack에 Push되는 과정을 살펴볼 수 있었다
JVM과 같이 컴파일을 저렇게 로우레벨로 진행한후 EVM에 넣는 식이다
Visibility
우리가 흔히 아는 가시성에 대한 부분이다. 사실 일반 언어와 다를게 없지만 Strorage State에서 값을 확인가능하다는 것을 언급하는데 이는 어찌보면 당연한것일수 있다. 이 값을 확인 불가능 하다면 투명성은 사라지는것이니까 → 프라이빗 못보면 이 숫자로 어떤 장난칠지 아무도 모르지 않는가
결국 컨트랙트끼리 못 읽게 설정한다는 점에서 프라이빗의 쓸모가 나타난다고 볼수있다.
아래 사진을 보면 저장이 안되어있는 경우 0x0 저장이 되면 맨뒤에 hex가 바뀌는걸 확인할수있다. 또한 스토리지 주소도 저장 할때 1이 증가하는것을 확인할수있었다
조금 더 궁금해서 스토리지와 메모리 스택을 더 찾아보았다. (사실 이전에도 찾아보았지만 한번더 다지고간다는 마음으로 찾아보았다.)
Stack 과 Memory Storage 그리고 Calldata
다음 글을 참고 하였습니다.
이더리움 백서 톺아보기 - 7편 - 업비트 투자자보호센터
EVM Storage에는 어떻게 변수가 저장될까? 저수준에서 확인하는 Storage 영역
[solidity] 메모리 구조와 Data location의 이해 - memory, storage, calldata
[Solidity 씨-리즈] 은근 헷갈리는 Data Location
[Solidity Memory. How does it work?](https://medium.com/coinmonks/solidity-memory-how-does-it-work-d40e04b97cf0#:~:text=Solidity reserved spaces&text=Memory never gets cleaned (no,only increases and never decreases.)
EVM 데이터관리
스택과 메모리는 개발자들에게는 꽤나 익숙한 개념이다.
정적 크기를 가진 Stack 선입후출 방식으로 컴파일한 스마트컨트랙트를 처리한다. 동적크기를 가진건 memory로 처리한다. 근데 사실 프로그래밍을 배우다보면 이와 비슷한 얘기를 많이 들을수 밖에 없다
근데 여기서 중요한 건 스토리지이다. 스토리지가 있음으로써 생기는 특별한 부분들이 있는데 일반 프로그래밍에서는 스토리지가 없다 즉, 스택과 힙으로 데이터를 관리하고 프로그래밍이 만들어진다. 스토리지가 EVM에 존재 함으로써 스택은 계속 스토리지에 쓰인 데이터를 참조해서 가져오며 메모리영역은 그떄 그때 필요한 데이터를 바꾸지 않고 가져오고 싶을 때 데이터를 복사해서 값을 가져온다.
한가지더 재밌는 사실은 GC가 없다는 사실인데 그렇기에 포인터값은 절대 줄어들지 않고 늘어난다 이떄 항상 포인터 초기값은 0x08이라고 한다. 그러므로 개발자가 직접 메모리를 조작해줄 필요가 있다
- 스택은 모든 값을 메모리와 스토리지에서 참조해서 가져온다.
- 메모리를 써서 데이터를 가져오면 복사되어서 주소가 아닌 값을 가져온다.
- 스토리지에 쓰이는것은 체인상에 영구적으로 저장된다.
- GC가 EVM에는 존재하지 않는다.
Contract with Setter Function
함수를 실행하고 실제로 Tx Data에는 어떤 값이 어떻게 들어가는지 확인해보았다
(즉 위 Hex는 setNumber(uint256)사용해 그때 쓰는 숫자는 1000이야!가 될것이다 간단하게 말해서!)
첫 4 byte가 함수의 이름 "setNumber(uint256)” 을 Keccak256으로 해쉬한 값이구나 라는 것을 직접 해당 사이트에서 확인 할수있었다 https://emn178.github.io/online-tools/keccak_256.html
요로코롬 스토리지 값이 바뀐것을 확인 할수있다 3e8은 우리가 저장한 숫자 1000이라는 것도 알수있다.
Verify
그리고 이더스캔의 중요한 기능도 하나 알았는데 바로 Verify기능이다.
내가 작성한 코드의 투명성을 증명하고 검증하는 과정으로써 이를 수행하게되면 한층더 안전한 코드라는것을 증명할수있다. 또한 컨트랙트에 내용을 작성할수도 있다.