[WIL] 앤틀러 4주차, BEB Solc 컴파일러

Back end Chain·2023년 4월 9일
0

Antler Korea Batch 2

목록 보기
5/6
post-thumbnail

앤틀러 2기 4주차 후기

Bootcamp3

월요일 아침, 지난주에 진행했던 Mini Idea Sprint를 마치고 서로의 피드백을 주고 받았다. 충분히 우리의 에너지 레벨과 Team-Fit이 잘 맞는 다고 느꼈다. 하지만 혹여나 다른 아이디어나 Team-Fit에 대한 아쉬움이 남지 않도록 이번 Bootcamp는 다른 사람들과 해보기로했다.

이번을 기회삼아 앤틀러 지원서에 작성한 나의 아이디어를 멋진 사람들과 검증해 볼 수 있었다. (앤틀러에 합격하기 위해서 반드시 아이디어가 필요한 것은 아니다.) 보통 Bootcamp에서는 나와 합을 맞춰보고 싶은 사람과 팀원을 구성해 문제를 찾고 솔루션을 찾지만, 이번에는 내가 관심있는 문제를 해결해보기 위해서 분야와 방향을 한정해두고 관심있는 팀원을 직접 모집했다. "AI시대에서의 작가의 권리 보호와 수익 다각화 문제". 한창 Generative AI중 하나인 Stable Diffusion이 엄청난 이목을 받고 있었고 당시 작가들이 겪고 있는 문제 현상을 발견했다. 앞으로 예술계가 어떤 방향으로 흘러갈 지 고민하며, 그들의 권리보호를 위한 방안을 찾고 있었다. 우연히 Adversarial Attack는 AI 학습을 방해해 모델을 공격하는 기술을 접했고, 이 기술을 이용해 작가들의 그림이 학습되지 않도록 막을 수 있을 것이라고 생각했다. 이번 Boot Camp를 통해 디지털 아트, AI, 조각 예술 등에 전문 분야와 비즈니스에 대한 폭넓은 이해가 있는 팀원들이 모였다. 내가 느낀 현상을 깊게 파고 들어가다 보니, "작가들은 그들의 작품이 AI에게 무단으로 학습되고 있는 지 여부를 알 수 없다"는 것이 문제이었다. 우리는 "명코(명탐정코난)AI"를 솔루션으로 AI 회사들에서 제공하는 학습데이터 Database에 작가의 작품을 검색하고 금액을 지불하면 쉽게 Opt-out할 수 있도록 제시했다. 나 스스로 이번 비즈니스는 앞으로 반드시 필요한 영역이지만, 매우 오랜시간 인식의 변화와 법제화가 필요한 부분이기에 더이상의 사업 아이디어로는 발전 시키기에 한계가 많다고 판단했다. 기회가 된다면 언젠가 개발자로써 풀고싶은 사이드 프로젝트로 만들어갈 생각이다.!

Trackout 준비와 첫 Office Hour

Bootcamp를 마치고 Mini Idea Sprint를 함께했던 Jessy와 본격적으로 Tarck out을 준비했다. 우리의 Team Fit과 해결할 문제, 솔루션을 Pitching을 통해 발표하고 심사를 거쳐 Trackout을 할 수 있다. Trackout 후에는 더이상 Idea Sprint와 Bootcamp로 공동창업자를 찾는 일을 진행하지 않고 본격적으로 시장에서 검증하며 PMF(Product Market Fit)을 찾아가야한다. 우리는 지난주에 이어서 계속해서 커리어 시장, 채용 시장, HR 시장의 문제를 정의하고 우리만의 솔루션을 찾아갔다. 팀에 열정이 넘쳐서 늦게까지 일하거나 밤을 새는 날도 있었다.

자신감있게 우리의 Solution을 들고 앤틀러 파트너님께 Office Hour를 신청했다. 아직 타겟과 검증 방법을 찾지 못해 Insight를 얻고 싶었고 Trackout를 위한 마지막 확인이라고 생각했다. 결국 문제정의부터 제대로 안되었다는 피드백을 받았다. 받은 피드백을 훑어보니, 분명히 부족한 부분이 명확했고 납득이 갔다. 문제정의가 정말 뾰족했다면, 타겟과 검증방법은 자연스레 찾아졌을 것이다. 받았던 피드백 중에서 "사용자가 이 서비스를 이용해서 얻는 목표가 무엇인가?"는 검증에 대한 내용을 담고 있었다. 적어도 이 서비스가 그 문제를 해결한다고 하려면, 검증에서도 사용자의 목표 달성까지 이뤄져야하기 때문이다. 그 날에 결국 모든 문제와 솔루션을 지우고 다시 시장의 현상과 문제부터 정리했고 주말에는 관련 자료를 더 찾아봤다.

백번들어도 어려운 말, "문제정의를 잘하자."


BEB 8기 Solc 컴파일러

Solidity 역시 Java와 동작 방식이 유사하다고 느껴졌다. 자바에 JVM이 있다면, 솔리디티에는 EVM이 있기때문이다. solc 컴파일러는 Solidity로 쓰여진 Smart Contract Code를 ABI와 Byte code로 컴파일 하고 EVM은 Byte code를 실행한다. 대부분 IDE에 익숙해져 이런 과정을 놓치곤 하지만, 언어의 특성과 흐름을 이해하는 데에 중요하다고 생각한다. 오늘은 Solc 컴파일러를 사용하는 방법을 정리해보고자 한다.

출처. https://kba.ai/the-story-of-an-ethereum-smart-contract/

설치 (MAC)

> brew update 
> brew tap ethereum/ethereum 
> brew install solidity

버전확인

solc --version

솔리디티 코드 컴파일

solc -optimize --bin {컴파일할 sol 파일 이름}
  • 여기서 -optimize 옵션은 컴파일전, 작성한 솔리디티 코드가 약 200회 실행된다고 가정했을 때를 기준으로 컨트랙트를 최적화한다.
  • 결과로 나온 16진수 이진코드를 EVM이 실행한다.

solc를 사용해 ABI(Application Binary Interface) 생성하기

solc --abi {컴파일할 sol 파일 이름}
  • ABI는 Smart Contract Code에 대한 설명이 담긴 JSON
  • ABI는 이더리움 네트워크에 있는 각 노드는 지갑을 통해 상호작용할 때 JSON-RPC 형식의 데이터로 상호작용하기 위한 데이터. Byte Code 형태만으로는 어떤 함수를 어떻게 실행해야하는 지 이해하기 어렵다.
  • ABI는 Smart Contract Code에 있는 함수에 대해 정의하고 인자값의 형태와 반환값의 형태를 가지고 있고 노드가 Contract 실행을 하기 위해 어떤 작업을 수행해야 하는 지 알려준다.

LinkedIn(링크드인)
Instagram @hk316_tostit

profile
"프로그래밍은 저의 상상을 실현 시킬 수 있는 유일한 도구입니다."

0개의 댓글