이달 31일자로 cypress 가 1.8.0 업그레이드가 되면 런던 하드포크를 지원하는 것으로 알고 있습니다.
그렇다면 cypress 에서도 솔리디티 0.8.13 버전을 안정적으로 지원하는 것이지요?
그에 맞춰 미배포 컨트랙트들을 0.8.13 버전으로 버전업을 하려는데 생각해보니 klaytn-contracts 들은 ^0.5.6 으로 작성되어있어서요.
openzeppelin 을 사용하면 되긴 하지만, KIP interface 라든지, 몇몇 함수 및 변수들은 openzeppelin 스탠다드와 조금 다르게 구현이 되기에, 클라이언트 문제고 있고 해서 KIP 스타일을 그대로 가져가고 싶습니다.
직접 일일이 버전업 해서 수정해서 구현해도 되긴 하지만… 업데이트 예정이면 더욱 안전하게 사용할 수 있을것 같아서요.
컨트랙 버전업이 예정되어있다면 배포가 언제쯤일까요?
안녕하세요.
Solidity 관련
런던 하드포크가 적용되면 말씀하신 것처럼 0.8.13 버전의 솔리디티 컴파일러를 사용하실 수 있습니다.
참고로 런던 하드포크가 적용되기 전에도 0.8.13 버전의 솔리디티를 사용하실 수도 있습니다. 단, 런던 하드포크에 적용되는 EVM 연산들을 사용하지 않는 조건으로요.
관련 내용은 Solidity Version과 EVM Version 사이에 상관관계가 있나요? 를 참고해보시면 좋을 거 같습니다.
Klaytn-contracts
GitHub - klaytn/klaytn-contracts 레포지토리는 3월 말 ~ 4월 중순 즈음에 업데이트가 예정되어 있습니다.
이 부분 참고 부탁드립니다.
1개의 좋아요
답변 감사드립니다.
말씀하신 부분은 EVM 버전에 따라 chainId 등의 opcode 사용 가능 유무를 말씀하시는 듯 합니다.
하지만 그 외에도 하드포크 시 특정 opcode 들의 cost 가 변하곤 했잖아요?
(베를린에서 스토리지 accessed 유무에 따라 sstore / sload cost 가 차이가 나듯이)
클레이튼은 자체 opcode cost 계산 방식을 갖기에 evm 버전에 따른 특정 opcode 사용가능 여부만 신경쓰면 되는건가요? (baseFee 기능이 추가된 것은 제외하구요.)
혹시 opcode cost 방식도 지금의 자체 계산법이 아닌, 이더리움의 cost 및 계산 방식들과 동일해질 가능성이 있나요? 혹은 그러한 방향으로 나아가는 중인가요?
그걸 알면 컨트랙트 작성 시, 가스 비용에 더 신경을 쓸 수 있을 것 같습니다.
accessed storage 고려라든지 fallback 함수나 send, transfer 함수 등 에서요.
Opcode cost 계산 방식은 최대한 이더리움과 동일한 방식으로 나아가는 중입니다.
그러나, Klaytn의 특성으로 인하여 적용 시점이나 상세한 값 자체는 달라질 수 있습니다.
예를들어, accessed storage 와 같이 기존의 Opcode cost 계산 방식을 변경시킬 수 있는 새로운 개념이 등장한다면 가능한 수용하는 쪽으로 개발하고 있습니다. 그러나, 기존의 Klaytn 트랜잭션 타입이나 내부 동작 방식과의 호환성이나 형평성 등을 고려하다보면 적용 시점이나 세부적인 적용 방식의 차이는 발생할 수 있습니다.
Opcode cost의 기본값은 이더리움과 동일하게 가져가고 있습니다. 그러나, Klaytn의 동작이나 Cypress 데이터 특성으로인해 특정 Opcode가 DoS 등에 대한 위험성이 있다 판단된다면, cost가 조금 다르게 설정될 수 있습니다.
결론적으로 Opcode cost 세부적인 차이가 발생할 수 있겠지만 이더리움에서 기존에 동작하던 컨트랙트가 Klaytn에서 동작하지 않게되는 일은 없도록하려합니다. 다만, gas cost 최적화 관점에서는 일부 다른 결과가 발생할 수 있습니다.
1개의 좋아요