이더리움 - Transaction

Transaction Structure란?

• Tranasction은 EOA가 EOA에게 Eth를 전송하거나 EOA가 CA(컨트랙트)를 호출할 때 사용되는 구조이다. (CA→CA호출(인터널 트랜잭션)은 트랜잭션이 기록에 남지 않는다)

• 이 데이터는 블록체인상에 기록된다.

type TxData interface {
	txType() byte
  copy() TxData

  chainID() *big.Int
  accessList() AccesList
  data() []byte // 컨트랙트 입력 데이터
  gas() uint64 //예상치의 가스값
  gasPrice() *big.Int //1gas마다 얼마의수수료가 발생하는지(일반적 10gwei)
  gasTipCap() *big.Int 
  gasFeeCap() *big.Int
  value() *big.Int // 실제 송금하려는 양
  nonce() unit64 // 송금하는 사람의 transaction은 몇번 날리고 있는지
  to() *common.Address

  rawSignatureValues() (v, r, s *big.Int) // 여기서 v, r, s는 타원곡선암호로 얻은 공개키로
  setSignatureValues(chainID, v, r, s *big.Int) // 서명을 하는데 사용된다.
}

트랜잭션 라이프사이클

1. 트랜잭션 해시가 암호화 방식으로 생성됨

2. 트랜잭션이 네트워크에 브로드캐스트 되어, 보류중인 트랜잭션들의 네트워크인 mempool 추가됨

3. validator들은 거래를 확인, success 블록에 추가

4. success된 블록은 곧 justified 에서 finalized 로 업그레이드 됨

이더리움 POS에서 트랜잭션이 만들어지는 과정

1. 트랜잭션 생성 및 브로드캐스팅
• 송신자는 개인 키로 트랜잭션을 생성하고, JSON-RPC API를 통해 노드에 요청
• 가스비와 팁 정의 → 기본 수수료는 소각되고, 팁은 검증자에게 돌아간다.

2. 트랜잭션 유효성 확인
• 트랜잭션을 받은 노드들은 Geth와 같은 실행 클라이언트를 사용해 트랜잭션 유효성을 확인
• 충분한 양의 이더가 있는지, 공개키를 사용해 송신자가 올바른 개인키로 서명을 했는지 확인
• 트랜잭션이 유효하면, mempool 에 트랜잭션을 추가하고 Gossip protocol 을 통해 노드들에게 트랜잭션을 브로드캐스팅
• Gossip : 노드가 탈중앙화된 P2P 방식으로 이웃 노드와 정보를 교환하는 통신 네트워크의 한 유형
• 브로드캐스팅을 받은 노드들도 자신의 mempool 에 트랜잭션을 추가한다.

3. Block Proposer
• Block Proposer 은 다음 클라이언트들로 이루어져 있다.
• Execution client
• 트랜잭션들을 모아 패키징하고, 로컬에서 실행하여 상태를 변경한다.
• 그 후 Consensus client에게 전달한다.
• Consensus client
• 받은 트랜잭션의 비콘 블록 을 생성하는 역할을 한다.
• 비콘 체인은 샤드 체인들이 병렬적으로 작동하면서, 동기화 상태를 유지할 수 있도록 하는 블록체인을 의미한다.

4. Validator
• Block Proposer가 아닌 Validator 노드들은 Gossip protocol 를 통해 새 비큰 블록 을 수신한다.
• 받은 비콘 블록 을 Execution client에게 전달해, proposal이 유효한지 확인한다.
• 이때 Validator Client를 이용해 재실행된 블록이 유효하다는 것을 증명한다.

5. 트랜잭션 완결(Finality)
• 블록이 네트워크에 스테이킹된 총 이더리움의 66% 이상으로부터 증명을 받으면 supermajority link 를 갖게 된다.
• 이때 트랜잭션이 supermajority link를 포함하는 체인의 일부가 되면 트랜잭션은 Finalized 된 것으로 간주할 수 있다.

트랜잭션 타입

• 일반 트랜잭션 : EOA-EOA

• 컨트랙트 배포 트랜잭션 : EOA-CA

• 컨트랙트 실행 : CA-CA

EOA-EOA간 거래

• Block : 몇 번째 블록에 이 트랜잭션이 포함되었는지에 대한 정보를 포함하고 있음을 체크.

• Value에 보내는 이더의 양이 들어가고 Input Data에는 빈 값이 들어감.

• Transaction Fee의 경우 gasPrice와 gasLimit을 곱한 값.

• Txn Type
• 0의 경우 기존의 EIP-1559을 적용받지 않는 타입.
• 1의 경우 EIP-1559의 적용을 받기 때문에 gasPrice, gasTipCap, gasFeeCap이 추가적으로 제공되어야함

• nonce 이 거래가 몇 번째의 거래인지를 알 수 있음

• position 익스플로러 사이트가 정제해보여주는 것으로 해당 블록에서 transition이 몇번째에 해당하고 있는지를 표시

• Input Data
• EOA-EOA 간의 거래의 경우 대체로 비어있음
• 특정한 거래 정보 조회시 사용할 수 있음

EOA-CA Transaction

• Value에 보내는 값이 없는 경우 0이 들어가고, Data에 호출하는 함수명과 파라미터 값이 들어간다.

• From :EOA의 주소

• Interacted With : CA의 주소로 contract로 시작.

• Value
• 일반적으로 0으로 보낸다.
• EOA가 Contract한테 value를 보내는 것이 아니라 함수를 호출

• Txn Type : 2인 경우 EIP-1559를 포함하고 있기 때문에 gasPrice, gasTipCap, gasFeeCap이 추가적으로 제공되어야 함.

• Input Data 함수명과 거기에 들어가는 파라미터를 적어줌.

CA-CA Transaction

• CA-CA간의 호출 정보는 Internal Transaction이라고 부르며, 코드 상에서 Delegatecall, StaticCall, call함수를 통해 발생한다.

• (CA-EOA ETH 전송, selfdestruct 포함)

Message(인터널 트랜잭션)

• message는 CA가 CA를 호출할 때 발생하는 네트워크 구조.
• 스마트 컨트랙트는 다른 스마트 컨트랙트들과 메세지를 통해 다양한 정보들을 주고받을 수 있다.

• EVM상에서만 존재하는 가상 객체
• 블록체인 상 기록이 남지 않음

Receipt 구조

• EVM에서 Transaction을 실행하고 결과값이 저장되는 곳.

• 실제로 사용된 Gas와 컨트랙트 호출 시에 발생하는 Log등이 저장되는 구조.

• 이 데이터는 블록체인 상 기록된다.

Meta Transaction

• 이더리움에서 제공하는 공식적인 타입은 아님

• 스마트 컨트랙트를 이용해 다른 사용자의 거래를 대신 수행해주는 방식

• ERC20 토큰 전송시 사용자가 ERC20 CA 호출을 위해 지불해야 하는 ETH수수료를 대행업체가 대신 납부할 수 있다.

EIP-2770 Code

• smart Contract 코드 상에서 사용자의 서명 검증하는 부분.

• Transaction서명 부분에서 진행했던 검증 방안과 동일한 방법으로 EVM상에서 진행된다.

• 호출한 사용자의 거래가 검증이 완료되면, CA-CA거래인 call을 통해서 대행 Contract가 토큰 전송을 대신 호출하게 된다.