Blockchain & Devops

ERC1155 ERC1155는 가스 효율적인 Token Contract를 만들기 위해서 이전 표준을 최대한 활용하기 위해 만들어진 토큰 표준이다. 좀 더 이해하기 쉽게 얘길하자면, 하나의 컨트랙트에서 여러 토큰을 발행해서 관리한다고 볼 수 있다. 심지어 ERC20, ERC721 모두 지원한다. 그래서 Multi-token standard라고 불린다. ERC1155의 특징은 단일 스마트 컨트랙트를 이용해서 여러 토큰을 한번에 표현 각 토큰 마다 고유한 id 를 기준으로 구분된 balanceOf 메소드를 호출 가능 모든 state를 하나의 컨트랙트에 존재하기 때문에 단일 트랜잭션에서 다양한 토큰 관리 가능 Features Batch Transfer: 여러 에셋을 하나의 Tx로 전송가능 Batch Balanc..

ERC721, NFT는 크립토에 관심이 없는 사람들도 아는 대표적인 토큰 유형으로 toknID 기준, 다른 토큰들과는 구별되는 고유한 특성이 있다. 워낙 유명해서.. 굳이 소개할 필요는 없을 것같다. 내가 활동하는 CURG 라는 블록체인 학회에서 관련 코드를 재정리했기 때문에 코드 구성을 한번 확인하고 정리해보려 한다. SolRoot/token/ERC-721 CURG 학회에서 진행하는 오픈소스 프로젝트인 SolRoot에서 ERC-721 코드 디렉토리는 다음과 같이 구성되어 있다. (Extension은 제외) ERC721Base.sol ERC721Extension.sol ERC721Metadata.sol ERC721SlotBase.sol ERC721Utils.sol IERC721.sol IERC721Enu..

짧게 TBA라고도 하는 ERC-6551은 NFT의 오너가 여러 컨트랙트를 컨트롤할 수 있는 권한을 가지고 있는 것이라고 보면된다. 즉, NFT + CA의 결합이라고도 보는데, 이 TBA의 NFT는 '지갑의 역할을 하기 때문에 누군가에게 양도되는 순간, 이 NFT에 있는 모든 자산도 그대로 양도된다. 디사이퍼 미디움에 따르면, 여러 유스케이스를 예상할 수 있다. Gas Fee 절약 NFT를 살때 개별 NFT마다 Tx가 일어나야했지만, TBA에 NFT Collection이 있다면 한번의 Tx로 모든 NFT를 구매할 수 있음 게임의 경우에도 하나의 NFT TBA안에 캐릭터와 물약, 아이템이 있다면 한번에 거래가 가능 보안의 향상 NFT 판매 시점에 ERC-20 토큰을 내재한 채로 판매하여 에어드랍 가능 별도의..

OpenZepplin 오픈제플린은 EVM 스마트 컨트랙트 개발에 많이 사용되는 오픈 소스 라이브러리다. 사실상 Solidity 기반 컨트랙트 개발에 있어선 표준으로 자리 잡을 정도로 사용된다. Security-Centric : 보안 전문가들에 의해서 검토되어 있으며, 실사용되고 있는 검증된 컨트랙트들로 구성되어 있다. Standard Contracts : ERC-20, ERC-721과 같은 표준 토큰 컨트랙트를 제공함. Reusable Components : 공통기능을 제공하는 다양한 스마트 계약 구성 요소를 포함하고 있어서, 개발자들은 이를 조합해 복잡한 기능을 빠르고 안전하게 구현가능. Community-Driven : 활발한 커뮤니티에 의해 지원되고 있으며, 보안과 최적화 및 기타 주제에 대해서 지..

대부분 쿠버네티스 기반 모니터링에 특화된 Prometheus Operator를 활용하여 job을 추가한다. Prometheus Operator를 사용하면 일일이 kubectl patch를 통해 configmap에서 job을 추가하지 않고도 Service monitor 혹은 Pod monitor라는 CR로 쉽게 등록이 가능하다는 장점이 있다. 그러나 문제는 Service Monitor를 apply했는데도, Target에 등록조차 안되는 상황이 올때가 있다. kubectl get servicemonitor 를 확인하면 오브젝트가 정상적으로 apply된 상태임을 알 수 있다. 에러 메시지도 확인할 수 없는 상황. 사실 프로메테우스 오퍼레이터는 초기 배포 시 namespace와 label 키 값을 설렉터로 지정..

Prometheus는 Memory와 CPU같은 하드웨어 리소스를 모니터링하는데 사용되므로 프로세스의 이벤트를 로깅하는데 한계가 있다. ELK 스택으로 개별 모니터링 파이프라인을 구축하기도 하지만, Grafana로 로깅에 최저화된 Loki를 사용하면 이미 Prometheus + Grafana로 메트릭을 수집하던 파이프라인에서 효율적인 로깅까지도 가능해진다. Loki Loki는 2018년 Grafana Lab에서 시작한 프로젝트로 수평 확장과 높은 가용성 그리고 멀티테넌시라는 특징을 가지고 있으며 낮은 비용에 운영이 간단하다. Store the logs in Loki Loki는 로그 텍스트를 인덱싱하지않고, 스트림으로 그룹화, 라벨링으로 인덱싱한다. 이를 통해서 비용 절감과 함께 로그 라인 쿼리를 짧은 시간..

Optimism의 op-batcher는 Layer1에 Tx Batch를 생성하여 압축, 전송하는 역할을 담당한다. 코드를 통해서 간단히 알아보자. # op-batcher func main() { oplog.SetupDefaults() app := cli.NewApp() app.Flags = flags.Flags app.Version = fmt.Sprintf("%s-%s-%s", Version, GitCommit, GitDate) app.Name = "op-batcher" app.Usage = "Batch Submitter Service" app.Description = "Service for generating and submitting L2 tx batches to L1" app.Action = cur..

L2 옵티미즘의 derivation이 어떻게 진행되는지를 정리해보려고 한다. derivation은 L2 체인을 derive하기 위해서 L1으로 부터 L2 derivation input을 읽는 과정이다. 내가 이해한 바로는 L1으로부터 필요한 정보를 가져와 L2 체인을 실행과 운영에 활용하는 것이다. 이 과정이 필요한 이유는 Layer2는 Layer1의 보안에 의존하기 때문에 트랜잭션 실행부터 Layer1 calldata 전송의 비용과 Layer2의 비용 산정, Deposit과 Withdraw를 안정적으로 진행할 수 있기 때문이다. Layer2라면 아주 중요한 파트 중 하나이며, 여기서 L2가 읽는 derivation input은 아래와 같다. L1 block attributes(block number, ..

Optimism의 Opstack은 약간의 코드 수정을 통해서 다양한 L1의 롤업을 지원할 수 있다고 생각한다. 여기서 L2의 트랜잭션 배치를 전송해야하기 때문에 L1의 정보를 derive할 필요가 있고, 그 과정을 이해해야한다. 최대한 이해할 수 있도록 정리해본다. L2 chain derivation 이는 간단히 말해서 L1의 데이터를 L2 블록으로 불러오는 것이라고 볼 수 있다. 이는 op-node(롤업노드)의 가장 중요한 역할이다. validate와 sequence하는 과정에서 L1의 데이터가 활용된다. 특히 L1의 re-org 이슈가 발생하면 L2에서 빠르게 대응해야하기 때문에 op-node의 역할이 더욱 강조된다. 각 L1 block은 L2의 시퀀싱 에포크에 맵핑되어 있다. 각 에포크 숫자는 L1..

옵티미즘의 베드락은 OP 메인넷의 주요 릴리즈 버전이다. 몇 가지 특징을 추려보자. Block Production Bedrock 버전 이후로 2초마다 새 블록을 생성한다. 기존에는 하나의 트랜잭션에 하나의 블록을 생성했었지만, 이젠 'TIMESTAMP'의 2초 간격으로 블록이 생성되며, 'BLOCKNUMBER'를 통해서 그 간격을 확인할 수 있다. System transactions Bedrock은 시스템 트랜잭션이라는 새로운 개념이 도입되었다. 시스템 트랜잭션은 op-node에 의해서 생성되는 것으로 L1 정보를 기록하여 deposit과 L2 업데이트에 활용된다. 모든 블록은 하나의 시스템 트랜잭션을 포함하며 이를 'L1 attrubutes desposited transaction'이라고 한다. 이는 ..