Gas optimization in Solidity, Ethereum
I’m sorry but my English is terrible. I hope you understand that generously.Recently, I was developing a toy project named Blind Market. It’s a simple P2P trading application using smart contract. I was making a contract using Solidity, and the trade stage proceeded in the order of pending, shipping, and done. The problem was appeared in done phase. The problem was that when I tried to close the transaction by paying the price raised by the seller in msg.value, the following error occurred.Pe...
Uvicorn & Gunicorn
Uvicorn and GunicornUvicorn and Gunicorn are important concepts when developing applications in Python. However, there are many concepts to be aware of in order to fully understand Uvicorn and Gunicorn. The following is a brief summary of the necessary concepts, and the details will be dealt with separately later.Necessary ConceptsStarletteStarlette is a Web application server that can run asynchronously. Starlette runs on top of Uvicorn.FastAPIFastAPI provides many features on top of Starlet...
P2WPKH
P2WPKHP2WPKH란 비트코인 내에서 가장 일반적인 스크립트 형식으로 비트코인 프로토콜에 대한 지불 거래 유형이다. 주소는 1로 시작하는데, 세그윗을 지원하는 새로운 주소 3 또는 bc1로 시작하는 주소보다 훨씬 비싸다. https://mirror.xyz/0xA1d9f681B25C14C1eE7B87f1CF102E73cA3ad4d9/egjhNVklgy_LgZmcTXXAOTBa6ePBqO3Ja9ZSoDIad-8 즉, 비트코인 주소가 1로 시작하면 P2PKH 주소를 사용하고 있는 것이다. 공개키의 간단한 해시이며, 이 해시를 주소로 사용하는 것이다. 이것은 원래 비트코인 주소 형식이었으며 오늘까지도 충실히 작동한다. 레거시 주소는 세그윗과 호환되지 않지만, 여전히 문제없이 P2PKH 주소에서 세그윗 주소로 BTC를 보낼 수 있다. 그러나 레거시 주소 트랜잭션이 더 크기 때문에 P2PKH 주소에서 전송하는 평균 속도는 세그윗 주소에서 전송할 때보다 더 높은 요금이 발생할 수 있다....
Smart Contract Developer, Web3 Backend Developer
Gas optimization in Solidity, Ethereum
I’m sorry but my English is terrible. I hope you understand that generously.Recently, I was developing a toy project named Blind Market. It’s a simple P2P trading application using smart contract. I was making a contract using Solidity, and the trade stage proceeded in the order of pending, shipping, and done. The problem was appeared in done phase. The problem was that when I tried to close the transaction by paying the price raised by the seller in msg.value, the following error occurred.Pe...
Uvicorn & Gunicorn
Uvicorn and GunicornUvicorn and Gunicorn are important concepts when developing applications in Python. However, there are many concepts to be aware of in order to fully understand Uvicorn and Gunicorn. The following is a brief summary of the necessary concepts, and the details will be dealt with separately later.Necessary ConceptsStarletteStarlette is a Web application server that can run asynchronously. Starlette runs on top of Uvicorn.FastAPIFastAPI provides many features on top of Starlet...
P2WPKH
P2WPKHP2WPKH란 비트코인 내에서 가장 일반적인 스크립트 형식으로 비트코인 프로토콜에 대한 지불 거래 유형이다. 주소는 1로 시작하는데, 세그윗을 지원하는 새로운 주소 3 또는 bc1로 시작하는 주소보다 훨씬 비싸다. https://mirror.xyz/0xA1d9f681B25C14C1eE7B87f1CF102E73cA3ad4d9/egjhNVklgy_LgZmcTXXAOTBa6ePBqO3Ja9ZSoDIad-8 즉, 비트코인 주소가 1로 시작하면 P2PKH 주소를 사용하고 있는 것이다. 공개키의 간단한 해시이며, 이 해시를 주소로 사용하는 것이다. 이것은 원래 비트코인 주소 형식이었으며 오늘까지도 충실히 작동한다. 레거시 주소는 세그윗과 호환되지 않지만, 여전히 문제없이 P2PKH 주소에서 세그윗 주소로 BTC를 보낼 수 있다. 그러나 레거시 주소 트랜잭션이 더 크기 때문에 P2PKH 주소에서 전송하는 평균 속도는 세그윗 주소에서 전송할 때보다 더 높은 요금이 발생할 수 있다....
Smart Contract Developer, Web3 Backend Developer

Subscribe to Primrose

Subscribe to Primrose
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
지난 Consensus Algorithm 글에서 Proof of Stake에 대해서 설명한 적이 있다.
작업증명의 합의 알고리즘은 블록체인 시대를 알리는 1등 공신이 되었지만 시간이 지날 수록 과도한 에너지 소비 및 채굴의 독점화가 발생하기 시작했고, 이에 새로운 합의 알고리즘에 대한 논의가 시작되었다.
그렇게 나온 합의 알고리즘이 바로 지분증명(PoS)이다.
지분증명이란 참여자의 소유 지분(Stake)이 블록 생성 권한에 반영이 되는 알고리즘을 일컫는다.
원리는 다음과 같다.
블록 생성 및 검증의 역할을 하는 Validator가 되기 위해서는 **자신이 보유하고 있는 암호 화폐를 보증금의 형태로 락업하는 특별한 거래(Special Transaction)**를 해야 한다.
그 이후에는 새로운 블록을 생성하고 검증하는 절차는 모든 Validator가 참여할 수 있도록 하는 특정 ‘합의 알고리즘(Consensus Algorithm)’에 의해 이루어진다.
여기서 중요한 점은 바로 특정 합의 알고리즘이 하나가 아니라는 것이다.
여기서 말하는 특정 합의 알고리즘이란, 지분증명이라는 큰 틀 안에서 블록 생성 및 검증, 그리고 보상에 관한 알고리즘을 말한다.
따라서 그 방법에 따라 지분증명은 다양한 형태가 될 수 있다.
가장 대표적인 형태로 오늘 소개할 ‘Chain-Based Proof-of-Stake’와 ‘BFT-Style Proof-of-Stake’가 있다.
Chain-Based Proof-of-Stake에서는 10초 단위의 매 슬롯마다 하나의 Validator를 의사 랜덤하게 (pseudo-randomly) 선정한다.
pseudo-randomly란, 난수를 흉내내기 위해 알고리즘으로 생성되는 값을 가리킨다. 이때 유사난수를 생성하는 알고리즘을 유사난수 생성기로 부른다. 유사난수는 알고리즘의 상태에 의해 값이 정해지므로 생성된 수열은 일정한 주기를 가지며, 따라서 난수의 예측 불가능성을 가질 수 없다.
선정된 Validator는 블록 한 개를 생성할 수 있는 권한을 갖게 된다.
그러나 생성된 블록은 반드시 이전 블록 중 하나를 가리켜야 하는데 보편적으로 길이가 가장 긴 체인의 마지막 블록을 가리키게 된다.
이에 결과적으로 대부분의 블록들은 단일의 체인에 모이게 되는데, 이 형태가 지분증명의 가장 기본적인 형태라고 볼 수 있다.
BFT-Style Proof-of-Stake에서는 Validator들에게 완전히 랜덤하게(randomly) 블록을 제안(propose) 할 수 있는 권한이 주어진다.
pseudo random vs randomly : 랜덤인데 아닌척하기 vs 랜덤
다만 어떤 블록이 정규 블록인지에 대한 합의는 여러 라운드에 걸쳐 이루어진다.
매 라운드 마다 모든 Validator는 특정 블록에 ‘투표’를 할 수 있다.
그리고 모든 라운드가 끝나면 Validator는 어떤 블록이 체인의 부분인지 아닌지 영구적으로 합의하게 된다.
특이한 점이 있다면 길이가 길거나 사이즈가 큰 체인의 블록이 남는 것이 아니라 많은 합의를 받은 단 한 개의 블록만이 남을 수도 있다는 것이다.
작업증명의 경우 대표적인 비트코인 사례가 표본이 되었다.
그러나 지분증명은 ‘참여자의 소유 지분이 블록 생성 권한에 영향을 미친다’는 의제를 큰 틀에서 공유하고 있을 뿐 세부적인 부분에 있어서는 많은 차이가 있다는 점에 유의하자.
지난 Consensus Algorithm 글에서 Proof of Stake에 대해서 설명한 적이 있다.
작업증명의 합의 알고리즘은 블록체인 시대를 알리는 1등 공신이 되었지만 시간이 지날 수록 과도한 에너지 소비 및 채굴의 독점화가 발생하기 시작했고, 이에 새로운 합의 알고리즘에 대한 논의가 시작되었다.
그렇게 나온 합의 알고리즘이 바로 지분증명(PoS)이다.
지분증명이란 참여자의 소유 지분(Stake)이 블록 생성 권한에 반영이 되는 알고리즘을 일컫는다.
원리는 다음과 같다.
블록 생성 및 검증의 역할을 하는 Validator가 되기 위해서는 **자신이 보유하고 있는 암호 화폐를 보증금의 형태로 락업하는 특별한 거래(Special Transaction)**를 해야 한다.
그 이후에는 새로운 블록을 생성하고 검증하는 절차는 모든 Validator가 참여할 수 있도록 하는 특정 ‘합의 알고리즘(Consensus Algorithm)’에 의해 이루어진다.
여기서 중요한 점은 바로 특정 합의 알고리즘이 하나가 아니라는 것이다.
여기서 말하는 특정 합의 알고리즘이란, 지분증명이라는 큰 틀 안에서 블록 생성 및 검증, 그리고 보상에 관한 알고리즘을 말한다.
따라서 그 방법에 따라 지분증명은 다양한 형태가 될 수 있다.
가장 대표적인 형태로 오늘 소개할 ‘Chain-Based Proof-of-Stake’와 ‘BFT-Style Proof-of-Stake’가 있다.
Chain-Based Proof-of-Stake에서는 10초 단위의 매 슬롯마다 하나의 Validator를 의사 랜덤하게 (pseudo-randomly) 선정한다.
pseudo-randomly란, 난수를 흉내내기 위해 알고리즘으로 생성되는 값을 가리킨다. 이때 유사난수를 생성하는 알고리즘을 유사난수 생성기로 부른다. 유사난수는 알고리즘의 상태에 의해 값이 정해지므로 생성된 수열은 일정한 주기를 가지며, 따라서 난수의 예측 불가능성을 가질 수 없다.
선정된 Validator는 블록 한 개를 생성할 수 있는 권한을 갖게 된다.
그러나 생성된 블록은 반드시 이전 블록 중 하나를 가리켜야 하는데 보편적으로 길이가 가장 긴 체인의 마지막 블록을 가리키게 된다.
이에 결과적으로 대부분의 블록들은 단일의 체인에 모이게 되는데, 이 형태가 지분증명의 가장 기본적인 형태라고 볼 수 있다.
BFT-Style Proof-of-Stake에서는 Validator들에게 완전히 랜덤하게(randomly) 블록을 제안(propose) 할 수 있는 권한이 주어진다.
pseudo random vs randomly : 랜덤인데 아닌척하기 vs 랜덤
다만 어떤 블록이 정규 블록인지에 대한 합의는 여러 라운드에 걸쳐 이루어진다.
매 라운드 마다 모든 Validator는 특정 블록에 ‘투표’를 할 수 있다.
그리고 모든 라운드가 끝나면 Validator는 어떤 블록이 체인의 부분인지 아닌지 영구적으로 합의하게 된다.
특이한 점이 있다면 길이가 길거나 사이즈가 큰 체인의 블록이 남는 것이 아니라 많은 합의를 받은 단 한 개의 블록만이 남을 수도 있다는 것이다.
작업증명의 경우 대표적인 비트코인 사례가 표본이 되었다.
그러나 지분증명은 ‘참여자의 소유 지분이 블록 생성 권한에 영향을 미친다’는 의제를 큰 틀에서 공유하고 있을 뿐 세부적인 부분에 있어서는 많은 차이가 있다는 점에 유의하자.
No activity yet