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 주소에서 전송하는 평균 속도는 세그윗 주소에서 전송할 때보다 더 높은 요금이 발생할 수 있다....
Ethereum Beacon chain
Beacon chain이더리움은 확장성 문제를 해결하기 위해 샤딩과 POS를 도입하기로 했다. 샤딩이란, 데이터베이스를 분할해서 데이터베이스의 부하와 체인의 지나친 중앙화를 막는 전략이다. POS란 지분 증명으로, 기존 POW와는 다르게 속도면에서 빠르다. POW는 컴퓨팅 자원을 소모해야만 합의 과정에 참여할 수 있지만, POS는 가지고 있는 ETH로 합의 과정에 참여할 수 있기 때문이다. 이더리움의 비콘 체인은 POS가 적용된 블록체인이다. 기존의 POW 가 아닌 이더리움 2.0을 위한 POS 가 적용된 블록체인이다. 비콘체인은 참여자들을 관리하는데, 어떤 검증자가 블록을 제안해야 할지, 위원회가 되어 블록을 증명해야 하는지 등의 역할을 한다.그림처럼 POW로 블록을 생성하는 메인 체인과 평행하게, POS 로 블록을 생성한다. 그러다 The Merge 업그레이드로 POW 가 아닌 POS 로 Mainnet 의 TX 처리를 시작하면서 블록 전파 및 합의 로직까지 담당하게 되었다....
Smart Contract Developer, Web3 Backend Developer
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 주소에서 전송하는 평균 속도는 세그윗 주소에서 전송할 때보다 더 높은 요금이 발생할 수 있다....
Ethereum Beacon chain
Beacon chain이더리움은 확장성 문제를 해결하기 위해 샤딩과 POS를 도입하기로 했다. 샤딩이란, 데이터베이스를 분할해서 데이터베이스의 부하와 체인의 지나친 중앙화를 막는 전략이다. POS란 지분 증명으로, 기존 POW와는 다르게 속도면에서 빠르다. POW는 컴퓨팅 자원을 소모해야만 합의 과정에 참여할 수 있지만, POS는 가지고 있는 ETH로 합의 과정에 참여할 수 있기 때문이다. 이더리움의 비콘 체인은 POS가 적용된 블록체인이다. 기존의 POW 가 아닌 이더리움 2.0을 위한 POS 가 적용된 블록체인이다. 비콘체인은 참여자들을 관리하는데, 어떤 검증자가 블록을 제안해야 할지, 위원회가 되어 블록을 증명해야 하는지 등의 역할을 한다.그림처럼 POW로 블록을 생성하는 메인 체인과 평행하게, POS 로 블록을 생성한다. 그러다 The Merge 업그레이드로 POW 가 아닌 POS 로 Mainnet 의 TX 처리를 시작하면서 블록 전파 및 합의 로직까지 담당하게 되었다....
Smart Contract Developer, Web3 Backend Developer
Share Dialog
Share Dialog

Subscribe to Primrose

Subscribe to Primrose
<100 subscribers
<100 subscribers
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.

I was conducting a test in the Remix VM environment, and there was no shortage of ether. But the pending status does not end.
But if there was any doubt, the turnIntoDone force was doing too much.
function turnIntoDone(uint256 tokenId, uint256 index)
public
payable
isApproved
returns (bool)
{
require(Trade[tokenId].phase == Phase.shipping);
require(
keccak256(bytes(UserInfo[msg.sender].nickname)) ==
keccak256(bytes(Trade[tokenId].buyer))
);
// Change phase
Trade[tokenId].phase = Phase.done;
// Seller nickname
string memory _seller = Trade[tokenId].seller;
// estimateFee
uint256 _fee = estimateFee(tokenId);
// Get fee
FeeRevenues += _fee;
// Transfer fee to smart contract
payable(address(this)).transfer(_fee);
// Transfer price to seller
payable(Trade[tokenId].sellerAddress).transfer(
Trade[tokenId].price - _fee
);
// Update Phase
TradeLogTable[UserInfo[msg.sender].nickname][index].phase = Phase.done;
TradeLogTable[_seller][index].phase = Phase.done;
// Mint Blind Token to buyer and seller
uint256 AmountOfBuyer = estimateAmountOfBLI(
Trade[tokenId].buyerAddress,
tokenId
);
uint256 AmountOfSeller = estimateAmountOfBLI(
Trade[tokenId].sellerAddress,
tokenId
);
mintBlindToken(Trade[tokenId].buyerAddress, AmountOfBuyer);
mintBlindToken(Trade[tokenId].sellerAddress, AmountOfSeller);
// Set users grade point
UserInfo[Trade[tokenId].sellerAddress].gradePoint += 1000;
UserInfo[Trade[tokenId].buyerAddress].gradePoint += 1000;
// Update users grade
updateUserGrade(Trade[tokenId].sellerAddress);
updateUserGrade(Trade[tokenId].buyerAddress);
safeTransferFrom(
Trade[tokenId].sellerAddress,
Trade[tokenId].buyerAddress,
tokenId,
1,
""
);
emit FinishPurchaseRequest(
Trade[tokenId].buyerAddress,
Trade[tokenId].sellerAddress,
tokenId,
Trade[tokenId].price,
Trade[tokenId].usedBLI
);
return true;
}
Looking at it again, it's really long and a lot of work. It became too long because I wrote the code first.
There were parts where data was obtained using the view function in the middle, I thought it was safer to call from inside the function than to call from the outside and get it and inject the data.
The first method I prescribed to solve the problem was to optimize gas. It seemed clear that this function would require a considerable amount of gas, even if this was not the cause.
So I started to rebuild the data structures in contract first.
// Governance Token
uint256 public constant BLI = 0;
// Fee ratio for each user grade
uint256 public NoobFeeRatio = 10;
uint256 public RookieFeeRatio = 9;
uint256 public MemberFeeRatio = 8;
uint256 public BronzeFeeRatio = 7;
uint256 public SilverFeeRatio = 6;
uint256 public GoldFeeRatio = 5;
uint256 public PlatinumFeeRatio = 4;
uint256 public DiamondFeeRatio = 3;
// Sum of fee revenue -> The total fees contract will have
uint256 private FeeRevenues;
constructor() ERC1155("http://BlindMarket.xyz/{id}.json") {
_tokenIdCounter.increment();
FeeRevenues = 0;
}
// Enum for user grade
enum Grade {
invalid,
noob,
rookie,
member,
bronze,
silver,
gold,
platinum,
diamond
}
// Enum for trade phase
enum Phase {
invalid,
pending,
shipping,
done,
canceled
}
// Struct for store user data
struct UserData {
uint256 gradePoint;
string nickname;
Grade grade;
}
// Struct for store information about each trade request
struct Request {
uint256 tokenId;
uint256 usedBLI;
uint256 price;
address buyerAddress;
string buyer;
string seller;
address sellerAddress;
Phase phase;
}
// Lock status of each NFT Token for product
mapping(uint256 => bool) MutexLockStatus;
// Mapping for user address and user information
mapping(address => UserData) UserInfo;
// Mapping for tokenID and trade request
mapping(uint256 => Request) Trade;
// Mapping for user nickname and total trade history
mapping(string => Request[]) TradeLogTable;
// Mapping for tokenID and token URI
mapping(uint256 => string) private tokenURIs;
// Governance Token
uint256 public constant BLI = 0;
// Fee ratio for each user grade
uint256 public constant NOOB_FEE_RATIO = 10;
uint256 public constant ROOKIE_FEE_RATIO = 9;
uint256 public constant MEMBER_FEE_RATIO = 8;
uint256 public constant BRONZE_FEE_RATIO = 7;
uint256 public constant SILVER_FEE_RATIO = 6;
uint256 public constant GOLD_FEE_RATIO = 5;
uint256 public constant PLATINUM_FEE_RATIO = 4;
uint256 public constant DIAMOND_FEE_RATIO = 3;
// Total fee revenue
uint256 private FeeRevenues;
constructor() ERC1155("http://BlindMarket.xyz/{id}.json") {
_tokenIdCounter.increment();
FeeRevenues = 0;
}
// Enum for user grade
enum Grade {
invalid,
noob,
rookie,
member,
bronze,
silver,
gold,
platinum,
diamond
}
// Enum for trade phase
enum Phase {
invalid,
pending,
shipping,
done,
canceled
}
// Struct for store user data
struct UserData {
uint256 gradePoint;
string nickname;
Grade grade;
}
// Struct for store user data
struct Request {
uint256 tokenId;
bytes32 hash;
string buyer;
string seller;
address payable buyerAddress;
address payable sellerAddress;
Phase phase;
}
// Lock status of each NFT Token for product
mapping(uint256 => bool) MutexLockStatus;
// Mapping for user address and user information
mapping(address => UserData) UserInfo;
// Mapping for tokenID and trade request
mapping(uint256 => Request) Trade;
// Mapping for user nickname and total trade history
mapping(string => Request[]) TradeLogTable;
// Mapping for tokenID and token URI
mapping(uint256 => string) private tokenURIs;
The first thing I tried was to reconstruct the variables of the structure.
I change the value type of usedBLI and price to uint128 from uint256.
Because the SSTORE command consumes a lot of gas, it was determined that it was necessary to pack the variables according to uint256.
Second is declare every fee ratio variable as constant variable.
Third is add encode and decode function for encoding two variable (usedBLI, price) and for decoding when we use them.
I judged that it would be more efficient to keep the encoded bytes32 variable instead of keeping the two variables in the structure. The encoding function and the decoding function were written as follows.
// Encodes "usedBLI" and "price" as "bytes32 hash".
function encode(uint128 _usedBLI, uint128 _price)
internal
pure
returns (bytes32 x)
{
assembly {
mstore(0x16, _price)
mstore(0x0, _usedBLI)
x := mload(0x16)
}
}
// Decodes "bytes32 hash" to "usedBLI" and "price".
function decode(bytes32 x)
internal
pure
returns (uint128 usedBLI, uint128 price)
{
assembly {
price := x
mstore(0x16, x)
usedBLI := mload(0)
}
}
Finally, local variable was actively used to minimize the number of times the storage data is read.
As I made the correction, the reason was actually payable.
There was a part of transferring to the contract using payable, and when I annotated that part, everything worked smoothly.
However, through this process, my knowledge of gas optimization seems to have improved than before, so I share it in writing.
Below are the links that helped solve the problem. It would be good to refer to.
https://yamenmerhi.medium.com/gas-optimization-in-solidity-75945e12322f
https://moralis.io/gas-optimizations-in-solidity-top-tips/
https://merrily-code.tistory.com/107
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.

I was conducting a test in the Remix VM environment, and there was no shortage of ether. But the pending status does not end.
But if there was any doubt, the turnIntoDone force was doing too much.
function turnIntoDone(uint256 tokenId, uint256 index)
public
payable
isApproved
returns (bool)
{
require(Trade[tokenId].phase == Phase.shipping);
require(
keccak256(bytes(UserInfo[msg.sender].nickname)) ==
keccak256(bytes(Trade[tokenId].buyer))
);
// Change phase
Trade[tokenId].phase = Phase.done;
// Seller nickname
string memory _seller = Trade[tokenId].seller;
// estimateFee
uint256 _fee = estimateFee(tokenId);
// Get fee
FeeRevenues += _fee;
// Transfer fee to smart contract
payable(address(this)).transfer(_fee);
// Transfer price to seller
payable(Trade[tokenId].sellerAddress).transfer(
Trade[tokenId].price - _fee
);
// Update Phase
TradeLogTable[UserInfo[msg.sender].nickname][index].phase = Phase.done;
TradeLogTable[_seller][index].phase = Phase.done;
// Mint Blind Token to buyer and seller
uint256 AmountOfBuyer = estimateAmountOfBLI(
Trade[tokenId].buyerAddress,
tokenId
);
uint256 AmountOfSeller = estimateAmountOfBLI(
Trade[tokenId].sellerAddress,
tokenId
);
mintBlindToken(Trade[tokenId].buyerAddress, AmountOfBuyer);
mintBlindToken(Trade[tokenId].sellerAddress, AmountOfSeller);
// Set users grade point
UserInfo[Trade[tokenId].sellerAddress].gradePoint += 1000;
UserInfo[Trade[tokenId].buyerAddress].gradePoint += 1000;
// Update users grade
updateUserGrade(Trade[tokenId].sellerAddress);
updateUserGrade(Trade[tokenId].buyerAddress);
safeTransferFrom(
Trade[tokenId].sellerAddress,
Trade[tokenId].buyerAddress,
tokenId,
1,
""
);
emit FinishPurchaseRequest(
Trade[tokenId].buyerAddress,
Trade[tokenId].sellerAddress,
tokenId,
Trade[tokenId].price,
Trade[tokenId].usedBLI
);
return true;
}
Looking at it again, it's really long and a lot of work. It became too long because I wrote the code first.
There were parts where data was obtained using the view function in the middle, I thought it was safer to call from inside the function than to call from the outside and get it and inject the data.
The first method I prescribed to solve the problem was to optimize gas. It seemed clear that this function would require a considerable amount of gas, even if this was not the cause.
So I started to rebuild the data structures in contract first.
// Governance Token
uint256 public constant BLI = 0;
// Fee ratio for each user grade
uint256 public NoobFeeRatio = 10;
uint256 public RookieFeeRatio = 9;
uint256 public MemberFeeRatio = 8;
uint256 public BronzeFeeRatio = 7;
uint256 public SilverFeeRatio = 6;
uint256 public GoldFeeRatio = 5;
uint256 public PlatinumFeeRatio = 4;
uint256 public DiamondFeeRatio = 3;
// Sum of fee revenue -> The total fees contract will have
uint256 private FeeRevenues;
constructor() ERC1155("http://BlindMarket.xyz/{id}.json") {
_tokenIdCounter.increment();
FeeRevenues = 0;
}
// Enum for user grade
enum Grade {
invalid,
noob,
rookie,
member,
bronze,
silver,
gold,
platinum,
diamond
}
// Enum for trade phase
enum Phase {
invalid,
pending,
shipping,
done,
canceled
}
// Struct for store user data
struct UserData {
uint256 gradePoint;
string nickname;
Grade grade;
}
// Struct for store information about each trade request
struct Request {
uint256 tokenId;
uint256 usedBLI;
uint256 price;
address buyerAddress;
string buyer;
string seller;
address sellerAddress;
Phase phase;
}
// Lock status of each NFT Token for product
mapping(uint256 => bool) MutexLockStatus;
// Mapping for user address and user information
mapping(address => UserData) UserInfo;
// Mapping for tokenID and trade request
mapping(uint256 => Request) Trade;
// Mapping for user nickname and total trade history
mapping(string => Request[]) TradeLogTable;
// Mapping for tokenID and token URI
mapping(uint256 => string) private tokenURIs;
// Governance Token
uint256 public constant BLI = 0;
// Fee ratio for each user grade
uint256 public constant NOOB_FEE_RATIO = 10;
uint256 public constant ROOKIE_FEE_RATIO = 9;
uint256 public constant MEMBER_FEE_RATIO = 8;
uint256 public constant BRONZE_FEE_RATIO = 7;
uint256 public constant SILVER_FEE_RATIO = 6;
uint256 public constant GOLD_FEE_RATIO = 5;
uint256 public constant PLATINUM_FEE_RATIO = 4;
uint256 public constant DIAMOND_FEE_RATIO = 3;
// Total fee revenue
uint256 private FeeRevenues;
constructor() ERC1155("http://BlindMarket.xyz/{id}.json") {
_tokenIdCounter.increment();
FeeRevenues = 0;
}
// Enum for user grade
enum Grade {
invalid,
noob,
rookie,
member,
bronze,
silver,
gold,
platinum,
diamond
}
// Enum for trade phase
enum Phase {
invalid,
pending,
shipping,
done,
canceled
}
// Struct for store user data
struct UserData {
uint256 gradePoint;
string nickname;
Grade grade;
}
// Struct for store user data
struct Request {
uint256 tokenId;
bytes32 hash;
string buyer;
string seller;
address payable buyerAddress;
address payable sellerAddress;
Phase phase;
}
// Lock status of each NFT Token for product
mapping(uint256 => bool) MutexLockStatus;
// Mapping for user address and user information
mapping(address => UserData) UserInfo;
// Mapping for tokenID and trade request
mapping(uint256 => Request) Trade;
// Mapping for user nickname and total trade history
mapping(string => Request[]) TradeLogTable;
// Mapping for tokenID and token URI
mapping(uint256 => string) private tokenURIs;
The first thing I tried was to reconstruct the variables of the structure.
I change the value type of usedBLI and price to uint128 from uint256.
Because the SSTORE command consumes a lot of gas, it was determined that it was necessary to pack the variables according to uint256.
Second is declare every fee ratio variable as constant variable.
Third is add encode and decode function for encoding two variable (usedBLI, price) and for decoding when we use them.
I judged that it would be more efficient to keep the encoded bytes32 variable instead of keeping the two variables in the structure. The encoding function and the decoding function were written as follows.
// Encodes "usedBLI" and "price" as "bytes32 hash".
function encode(uint128 _usedBLI, uint128 _price)
internal
pure
returns (bytes32 x)
{
assembly {
mstore(0x16, _price)
mstore(0x0, _usedBLI)
x := mload(0x16)
}
}
// Decodes "bytes32 hash" to "usedBLI" and "price".
function decode(bytes32 x)
internal
pure
returns (uint128 usedBLI, uint128 price)
{
assembly {
price := x
mstore(0x16, x)
usedBLI := mload(0)
}
}
Finally, local variable was actively used to minimize the number of times the storage data is read.
As I made the correction, the reason was actually payable.
There was a part of transferring to the contract using payable, and when I annotated that part, everything worked smoothly.
However, through this process, my knowledge of gas optimization seems to have improved than before, so I share it in writing.
Below are the links that helped solve the problem. It would be good to refer to.
https://yamenmerhi.medium.com/gas-optimization-in-solidity-75945e12322f
https://moralis.io/gas-optimizations-in-solidity-top-tips/
https://merrily-code.tistory.com/107
No activity yet