P2P Address Lookup을 할 때 노드 주소를 넣는데, 이를 Topic으로 처리해서 생기는 문제입니다.

TODO

• Use protobuf for nameserver.Lookup()

@therne grpc에서 받은 컨텍스트를 넣어주세요 새로운 컨택스트를 생성해 사용하면 timeout이 된 이후에도 무한정 기다리는 문제가 발생합니다.

Related #44

account/client.go 38번째 줄에서 api 패키지에 있는 struct를 사용합니다.

Purpose

• API 레이어와 서비스 레이어의 분리
• 서비스 레이어를 클라이언트 SDK로 재사용할 수 있게 (like go-ethereum)

Requirements (Action Items)

• Python의 gRPC API를 포팅
• 에어블록 내 모든 Service들을 포함하는 컨테이너가 있어야 함 (e.g. geth의 eth.EthereumBackend)
• Service 내에서는 해당 컨테이너의 존재를 모름. Seperation-of-Concerns
• Service간의 Peer-dependency를 지원해야 함 (e.g. DataService가 WarehouseService 참조)

Definition

Data Transaction은 Data Provider가 Data Consumer에게 어떤 데이터에 대한 접근 권한을 허용했다는 내용이다.
Data Transaction은 최소한 다음과 같은 4개의 필드를 포함한다.

• id: 8바이트 ID
• from: Data Provider Account ID
• to: Data Consumer Account ID
• data: 데이터 ID의 목록. 데이터 ID는 bundleID/userID의 16바이트로 구성된다.

Data Transaction Manager (DTM)는 해당 Data Transaction을 관리하는 컨트랙트이다. 기능은 다음과 같다.

1. 자신이 날린 Data Transaction 목록을 조회
2. 자신을 대상으로 하는 (to Field, 즉 내가 소유한 데이터) Data Transaction 목록을 조회
3. Data Transaction ID를 바탕으로 트랜잭션 내용을 조회
4. 새로운 Data Transaction을 일으키기

예를 들어, 데이터 거래가 체결된 후엔 DTM을 통해 Data Transaction이 발생되어 실제 데이터 소유권이 부여된다. 이후 데이터 컨슈머는 Re-Encryption Proxy에게 어떤 데이터에 대해 자신을 대상으로 하는 Data Transaction의 ID를 제시해야 한다. Re-Encryption Proxy 노드는 해당 Data Transaction ID를 보고 트랜잭션 내용을 조회한 후, 그것이 해당 컨슈머의 것이 맞으면 재암호화 키를 반환할 것이다.

이는 Data Permission Table이 트랜잭션 형태로 구현된 것이라고도 볼 수 있다. 굳이 Permission Table을 사용하지 않고 DTM을 통해 번거롭게 데이터의 소유권을 관리하는 이유는 Phase 2에서의 Scalability 확보를 위해서다. Phase 1에서는 단순히 데이터 트랜잭션 안에 모든 거래 대상 데이터의 ID를 전부 포함시키지만, Phase 2에서는 Accumulator를 사용하는 것을 목표로 하기 때문이다.

Phase 1

한번의 Ethereum Transaction에 들어갈 수 있는 Data ID의 양은 제한되어 있으므로, Data Transaction을 생성할 때 여러번의 Ethereum Transaction을 일으켜서 트랜잭션을 build할 수 있어야 한다.

Phase 2

Some cryptoeconomic magic— To be described 👀

Research Needed

• Exchange의 Order와, Data Transaction을 통합할 수 있는 여지가 있다. 예를 들어 데이터 프로바이더가 그냥 댓가를 받지 않고 어떤 컨슈머에게 소유권을 이전하고 싶다면 Exchange에서 Order를 날릴 때 escrowContract = null로 지정하고 날리면 똑같은 효과가 나기 때문. 무엇이 더 좋을까?

Requirements (TODO)

• Exchange 이후에 Data Transaction을 날려서 소유권 이전이 가능함
• Consumer는 자신이 소유한 Data Transaction 목록을 DTM 컨트랙트를 통해 조회할 수 있음.
• (Phase 1) 여러 번의 Ethereum Transaction을 통해 Data Transaction을 생성할 수 있음
• Data Transaction ID를 통해 트랜잭션 내용을 조회할 수 있음

Steps To Reproduce

• TBD

Cause

• Account Proxy는 한개의 EOA를 사용하기 때문에 동시다발적인 Account Creation 요청에 대해서 당연히 nonce too low 에러가 발생할 수밖에 없음. Account Spliting과 Waiting Queue 등을 만들어야 할 것으로 보임.
  • 비동기화된 Account Creation을 지원하도록 RPC 디자인을 조금 바꿔야 함.

Purpose

• Airbloc Client API의 사용에 대한 통계 제공
• 데이터에 대한 통계 제공
• TBD

Research Needed

• About Prometheus

Requirements

• Airbloc Client API 사용에 대한 통계를 Prometheus로 로깅
  • https://github.com/grpc-ecosystem/go-grpc-prometheus
• 데이터에 대한 통계 제공

When sending DAuth/SignIn request to UserDelegate node,
Airbloc node intermittently invokes lookup error.

hash는 일단 기본적으로 32byte 정보이기 때문에 string으로 보내기 위해서는 hex로 바꾸어서 보내야 합니다.
이에 대하여 ethereum과의 호환성을 위해 geth common패키지에 있는 HexToHash, HexToAddress를 사용하여 변환하게 된다면 여러가지 이점을 취할 수 있을것 같습니다.

Linked with #36 , #15

Purpose

• 많은 수의 사용자 데이터를 등록하기
• 많은 양의 사용자 데이터를 거래하기

Proposal

Background

가장 쉬운 방법은 Mapping을 사용하는 것이다. 하지만 이는

Proposed Solution

SMT와 Challenge Protocol을 사용한다.

Limitations

• SMT Construction이 필요하다.

Requirements

Identity Manager (#21)을 User Delegate와 Account Proxy로 쪼갠다.

Purpose

• Provider의 견제: 현재 Provider는 API를 통해 DAuth를 맘대로 수행해버릴 수 있다. 이를 방지하기 위해, 사용자 활동을 감시하고 필터링하는 User Delegate라는 노드를 중간에 하나 더 두고 Provider의 활동에 대해 사용자에게 알림으로서 Provider를 견제할 수 있다.
• My Data Ownership: 자신의 데이터에 대한 모든 통제권을 갖고 싶으면, User Delegate 노드를 직접 돌리면 된다.
• Private-key-less한 Airbloc 사용을 하려면, 중간에 Proxy로서 콜을 대신 수행해주는 노드가 필요하다. (Account Proxy와 역할이 겹침)

Consideration

• User Delegate의 예방적 신뢰 장치: User Delegate는 (자신이 Delegate하는 User들에 한해서) 임의로 설정을 조작할 수 있다. 물론 유저는 얼마든지 Notify할 수 있기 때문에, 유저는 자신의 설정이 바뀌면 Delegate를 바꾸는 방식으로 대응할 수 있지만 이는 후행적인 처리이며 Delegate는 사실상 어떠한 패널티도 입지 않는다. 따라서 예방적 신뢰를 보장할 수 있는 프로토콜을 설계하거나, 챌린지 프로토콜 등의 도입을 통해 확실한 패널티를 부여해야 한다.

• Fallback User Delegate의 설정 : 현재 DAuthSignup시 User Delegate가 없으면 Fallback User Delegate인 Airbloc Tracker가 설정되도록 하드코딩되어있다. 물론 일단 Airbloc Tracker를 Delegate로서 SignUp한 이후에 setDelegate를 통해 Delegate 권한을 임의로 옮겨올 수 있지만, 궁극적으론 UX단에서 DAuthSignup시 User Delegate (a.k.a "Tracker Service")를 사용자가 직접 지정할 수 있게 해야 한다.

Requirement

• CLI에 userdelegate로서 돌아갈 수 있는 옵션을 추가
• server API와 userdelegate API 분리
• Accounts에서 Delegate 지정
• Delegate를 새로 지정하려면 직접 트랜잭션을 날려야 한다.
• DAuth에서 이제 Provider는 직접 블록체인 콜을 하는게 아니라, 단순히 User Delegate에게 P2P로 요청을 수행하고 User Delegate가 직접 블록체인 인터렉션을 하게 됨.
• 이미 DAuth로 바꾼 설정은 Delegate가 오버라이딩하지 못한다.
• Delegate가 DAuth 설정을 변경했을 때 별도의 event를 emit한다.

Purpose

• Prepare for Open-Source
• Human-Readable Code
• Automatic Developer Reference Generation

Research Needed

• Frontend에서 어떻게 보여줄 것인가?
• 어떤 Framework로 보여줄 것인가?
• 어떤 레퍼런스 말고도 가이드가 필요할까?
• Developer Center?

Requirements (TODO)

• References
  • Documentation in every public component
  • Documentation Generation Framework Integration
  • Frontend UI (+ Design)
• Guides
  • Installing (Building) Airbloc Node
  • Installing SDK
  • Architecture
  • Registration
  • Upload Data
  • DAuth
  • Exchanging a data
  • Repository Readme
  • Contribution Guidelines
  • TBD...

Related #13 #4 #3

• 추상화
  • 인터페이스 정의
  • Host
  • DHT
  • + Package
• Discovery
  • Custom CID
  • Escape from /ipfs/

생각보다 Libp2p가 ipfs라는 application을 위해 만들어졌다는 느낌이 강하게 듦
그래서 더 많은 Customizing을 하기 위해서는 시간이 더 필요할것 같음.
일단 ipfs의 형식에 맞추어 제작을 하되 그 이상의 작업은 천천히 해나가면 될듯함

Start() -> Start(context.Context)

Purpose

• 예쁜 에러처리
• 디버깅이 쉬운 좋은 로거

Research Needed

• Panic - Recover 패턴
• glogger in Geth?

Bundle 의 요구사항은 다음과 같습니다.

• 앞에 Header가 위치
• 번들 안에서 i번째 데이터를 가져올 수 있어야 함

Row-based JSON (Current)

Pros:

• Easy to code
• Easy to debug
• Platform-wide

Cons:

• Heavy
• Slow
• Doesn't support raw byte encoding

BSON

Pros:

• Compact
• Raw-byte encoding (Binary Protocol!)

Cons:

• Doesn't support row-based retrieval
• Hard to debug

Apache Avro

Pros:

• Row-based Retrieval
• Fast
• Compact
• Enterprise Friendly (Especially Hadoop Infrastructure)

Cons:

• Isn't it over-engineering?
• Worse at Column-based Retrieval
  • e.g) Aggregate only payload / ANID

Apache Parquet

Pros:

• Column-based Retrieval
• Fast
• Compact
• Enterprise Friendly (Especially Hadoop Infrastructure)

Cons:

• Isn't it over-engineering?
• Worse at Row-based Retrieval
  • e.g) Retrieve data on ith index

Purpose

• 노드가 들고 있는 Re-Encryption Key를 동기화하고 관리함

Research Needed

• Due Diligence of NuCypher as a Proxy Re-Encryption (PRE) network
• Integration with multiple personal account system

Requirements (TODO)

• Base Architecture is KeyManager from airbloc-py
• Owner Key를 불러올 수 있어야 함
• PRE 네트워크를 추상화해야 함
• PRE 네트워크에서 데이터에 해당하는 Re-Encryption Key를 가져올 수 있어야 함
• 가져온 Re-Encryption Key를 LocalDB에 저장해야 함
• Sync : 자신의 모든 데이터에 대해, Re-Encryption Key를 불러와서 저장함

Purpose

• User-Password 기반의 회원가입 및 에어블록 사용 (DAuth, etc...)
• Airbloc Node (Account Proxy)에 Password Signature를 이용해 접근

Requirements

• Proxy를 거쳐 Wallet Address, Password를 통해 Account를 만들 수 있어야 함
• Proxy를 거쳐 Identity (e.g. Email), Password를 통해 Temporary Account를 만들 수 있어야 함
• Password를 통한 Key Derivation
• Accounts 컨트랙트에서 Password Signature를 통한 Authentification을 지원

Purpose

• TBD

Requirements

• TBD

ECDSA key 만들때 길이가 31인 []byte가 생성이 되는것 같음
그래서 길이 체크하고 안맞으면 padding rune으로 넣어주는 방법을 생각중인데 어떻게 생각하시나요
@therne

현재는 Bundle ID를 클라이언트단에서 제네레이팅함.
하지만 이렇게 할 경우 Colision등의 문제가 생길 수 있으므로 컨트랙트단에서 하는게 필요함.

고려사항:

• State Channel의 수용

1. Hash, ID, DataID 모두 bytes에서 string으로 바꾸기.
2. 이에 맞추어서 common패키지에 적절한 변환 함수 추가
3. manager에게 적용

https://medium.com/day34/solidity-0-5-0-%EC%97%90%EC%84%9C%EC%9D%98-%EB%B3%80%EA%B2%BD%EC%82%AC%ED%95%AD%EC%9D%84-%EC%86%8C%EA%B0%9C%ED%95%A9%EB%8B%88%EB%8B%A4-ab6104296164

low level 호출에 대한 return값으로 success여부와 returnData를 받게됩니다 오예!
만약 적용하게된다면 Exchange단의 작업 기간이 조금 더 늘어날것 같네요 그 점 유의해주세요

두 API의 역할이 겹치는 부분이 많습니다. 지금은 분리가 힘들지만, 장기적으로 천천히 분리하는 방향으로 가면 좋을것 같습니다.

Purpose

• 사용자의 편에 서있는 Online Node가 필요하다.
  • 이상적으론 개인당 1인 1노드지만, 현실적으론 호스팅이 필요함
• 여러 앱에서 수집되는 중복되는 Identity 정보들을 모아서 관리하는 Data Provider
• Identity Matching을 통해, Consumer -> User까지의 리치를 도와주는 일종의 Relayer
• 사용자에게 데이터 사용에 대한 고지를 해주는 일종의 Tracker Service

Research Needed

• Private Identity Matching (Please refer Technical Whitepaper)
• 아이덴티티 정보와, 그에 대한 Proof (e.g. Hash of Identity Data)을 어떻게 관리할 것인가?

Requirements (TODO)

• Identity Data Type
  • Data Type을 Identity, Payload로 나눠야 함
• On-chain Identity Manager Registry
  • Register 및 Stake가 가능해야 함
  • Slash가 가능해야 함
• Identity Providing
  • DAuth 단계에서 Identity Manager를 지정하면, 해당 Identity Manager가 그 Identity Data의 Data Provider가 되어야 함.
  • Airbloc Network를 통해 Identity가 전송되어야 함 (Linked with #13 )
  • Identity Provider가 해당 Identity 데이터를 등록해야 함
• Identity Matching
  • Airbloc Network를 통해 Identity Matching이 구현되어야 함
  • Identity를 넣으면 ANID가 나와야 함

네이밍이 꼬이면서 하나로 통일을 해야된다는 생각이 들었습니다.

Related with #40

Problem

• Only distinct users can be ingested at a bundle.
  • Due to the limitations of the current merkle dataset structure, only a user can be placed at the leaf of the sparse merkle tree.
• Because of the limitation, we should need to make some data ingestor— which splits incoming data by collections, and make them only contain distinct users.

Actions

We need to refine current bundle data structure by allowing multiple users to be placed into the leaf of the SMT. This may require following tasks:

• Introduce Data ID
  • (Should not be placed anywhere on-chain, except for data exchanging phase 1)
• Re-Introduce Bundle ID
• Refine Merkle Data Set Structure
• Change Merkle Proof Generation

Purpose

무엇에 관한 이슈인지 빠르게 파악하기 위함

Requirements

지금 커밋하는 형식대로
앞에 주제를 달면 좋을것 같네요
[Common]
[Contract]
[Collection]
이런 형식으로요

Details

• P2P Message 전송 시 dial backoff error가 간헐적으로 발생함.

Condition

• dev server에 server, userdelegate를 띄워놓았을 때
  • 일반 local의 노드에게도 영향을 미침.

Purpose

• P2P 메세지는 현재 Fire-and-Forget임. 문제는 DAuth Request같은 경우에는 User Delegate 노드가 오프라인일때도 무조건 전송되는게 보장되어야 한다.

Requirement

• 오프라인에 Retry Message 저장
• 전송에 대한 ACK 구현
• 주기적으로 Retry하기 (혹은 Binary Backoff 등을 사용할 수 있음)
• TTL (Time-To-Live) 구현

우리가 interface를 만들지 않아서 생긴 문제라 interface를 선언해놓자,
그리고 Mockgen으로 generate하면 간단하게 해결되는 문제.

• Collection Registry
• Schema Registry
• Rebuild Account Package (go-style)
• Database
  • LocalDB
  • MetaDB
• Exchange

• ethereum account (ecdsa)
• metadb account (ed25519)

합쳐서 새로 생길 airbloc용 client struct에 넣자

sync가 필요한 부분 (contract <-> localdb)

• collection registry
• schema registry
• app registry

생각해봐야할 점은

• sync가 꼭 필요한가?
• sync가 필요한 서비스들과 필요하지 않은 서비스를 분리
• 전용 프로토콜을 개발...?
  • 풀노드와 연결해서 모든 블록을 조사한 다음 이벤트를 필터링하는 작업은 매우 느릴 뿐만 아니라 풀노드를 운영하는 주체에게도 많은 부담을 안긴다.
  • 그렇다면 p2p protocol로 localdb를 공유하는건 어떨까?
  • 이렇게 되면 localdb에 저장되는 event정보는 그 event가 어떤 블록에 속해있는지, 그리고 그것을 검증할 수 있는 proof이 추가되게 됨.

Purpose

To validate the data by using Sparse Merkle Tree as a User ID accumulator (#40), efficient construction of the Sparse Merkle Tree is required because it's still not very cheap.

• Massive, Fast Data Validation
• To cache the tree data in LocalDB

Research Needed

• Optimizing Sparse Merkle Trees — vbuterin

Requirements

• SMT의 Serialization이 가능해야 함
• SMT를 LocalDB에 저장할 수 있어야 함
  • TTL (Time-To-Live) Control

Purpose

• New Developer Onboarding : 새 개발자들이 유닛 테스트 작성 및 분석을 통해 코드를 익힐 수 있게
• CI Integration
• Test code without running a daemon or E2E (End-to-End) Tests

Requirements (TODO)

• Golang Unit Tests
• Solidity Unit Tests
• More than 80% coverage!
• CircleCI Integration 되어야 함
• coveralls로 통합되어야 함
• README.md에 해당 Badge 통합
• Github PR 파이프라인에 CI 테스트 넣기

a.k.a. Airbloc Network

Purpose

• Exchange 과정에서의 Re-Encryption Key 요청 및 공유
• Identity Matching
• Data Index Sync 과정의 단축? (Mentioned in #4 )
• Interactive Challenges (ex: Data Availability Challenge)

Requirements

• libp2p 사용
  • Encrypted Channel 지원
  • Kademila DHT
• Protocol Definition using Protobuf
  • Prysm의 Protobuf를 이용한 p2p / rpc 인터페이스 정의 샘플 참고
• Abstractness: 어디에서든 간편하게 쓸 수 있어야 함. (LocalDatabase 인터페이스처럼!)

Research Needed

• TCP Transport vs QUIC Transport
• Node Discovery 및 Identification Rule을 어떻게 할 것인가?
  • e.g) DevP2P의 DiscV4에선 노드가 가진 Public Key를 ID로 사용하고, 이를 통해 Distance를 구한다.

  distance(n₁, n₂) = keccak256(n₁) XOR keccak256(n₂)
  

  • libp2p에 좋은 transport 샘플들이 많음.

TODO

• libp2p Integration
• Protobuf로 P2P Protocol Layer 구성
• bootstrap 노드 데몬 구현
• Sample Ping-pong node Test

In extension of #49...

Purpose

• App Manager는 악성 앱을 거르고 앱에 Slashing Condition을 부여하기 위해 담보로 ABL을 Staking하는 것을 요구한다. 따라서 App Manager에 🥩기능이 포함되어야 한다.

Research Needed

• Using Token Curated Registry (TCR)
• Staking Bond Requirements
• Slashing Conditions

Requirements

• 더 많은 메타데이터 저장
  • 앱 아이콘 URL 저장
  • appName과 displayName을 구분함
  • 웹 서비스인 경우 도메인 저장
  • 앱인 경우 앱마켓 URL 저장
  • i18n에 대한 고려
  • IP 및 Origin에 대한 화이트리스트 저장
    • 이걸로 시빌어택을 막을 순 없지만, 프론트단에서 편리한 보안 기능을 제공합니다. geth의 Authentification 기능과 포지션이 유사할 수 있다고 생각하면 될 것 같습니다.
• 🥩
• TBD...

Purpose

• Runnable Airbloc!
• Configuration 설정

Requirements (TODO)

• Commons
  • 임의의 YAML Configuration File에서 값을 읽음
  • 모든 Service에 필요한 Config을 제공해야 함
  • Flag를 통한 Config 오버라이딩
  • 환경변수를 통한 오버라이딩
• Server
  • airbloc run을 쳤을 때 gRPC 서버가 작동해야 함
  • HTTPS Support
• Sync
  • airbloc sync를 쳤을 때 싱크가 되어야 함

Purpose

패키지를 분리해서 SDK로써 이 프로젝트를 사용할때 api와 관련된 쓸데없는 파일들이 같이 들어가지 않게 막는다.
ex) dep으로 geth를 사용하는 경우, 사용하고 있는 패키지만 받아오고 나머지 패키지는 받아오지 않는다.

Requirements

• Collections
• Schemas
• Account
• Warehouse
• Data
• Exchange

• Fix broken build
• Update Readme for building on scratch

• Warehouse
  • S3 Driver
• Data
  • Batch support
• Crypto
  • Key Manager Sync

Additional Works?

• KeyManager

현재 통일되어 있지 않은 ID 형식을 8바이트로, 다음과 같이 통합합니다. 모든 ID는 컨트랙트에서 만들어져야 합니다.

bytes8(keccak256(block.number, msg.sender /* or AccountID */, someUniqueInfo))

적용 범위

• Account ID
• App ID
• Schema ID
• Collection ID
• Bundle ID

기존에 있는 contract bind는 다음과 같은 문제점이 있음

• call과 transact를 해야하는 함수들이 분리가 되어있지만, contract-dependent해서 통합적으로 관리할 수 있는 interface가 없음
  • 이게 왜 문제냐면 많은 contract들을 컨트롤해야하는 상황이 생겼을 경우 컨트랙트별로 따로 코딩을 해줘야 한다는 엄청난 낭비가 생김
  • 나중에 통합 client를 만들때 통합된 interface가 없다면 지금 상태의 조잡한 ethclient를 사용해야 한다.
• event를 parse할 수 있는 함수가 정의되어있지 않음
  • 이게 왜 문제냐면 그냥 호출만 해도 되는걸 직접 ABI 따가지고 Unpack해서 파싱해야됨
  • 이벤트별로 파싱함수 따로 만들고있으면 자괴감이 든다.

해결방법은 go-ethereum의 bind패키지에 있는 bind generation template와 script를 수정해서 pr를 날려보자

Purpose

• Runnable Airbloc
• End-to-end Test

Requirements

• API 서버 동작
• 임의의 Config을 집어넣을 수 있어야 함

Dep이랑 하위호환되기때문에 해서 나쁠건 없지 않을까용?

Requirements:

• GO111MODULES=on

App Registry, without 🥩

Purpose

• 데이터 프로바이더 등록을 위한 API
• E2E 테스트를 보다 더 완전하게 완성
• 나중에 에어블록에서의 활동에 앱을 추가하기 위함

Requirements

• 앱 이름과 앱 설명을 통해 앱을 등록해야 함
  • 앱 설명은 MetaDB에 저장
• 앱 정보를 가져올 수 있어야 함
• 간단한 Create, Read API

TODO (In the Next Phase)

• 더 많은 메타데이터 저장
  • 앱 아이콘 URL 저장
  • appName과 displayName을 구분함
  • 웹 서비스인 경우 도메인 저장
  • 앱인 경우 앱마켓 URL 저장
  • i18n에 대한 고려
  • IP 및 Origin에 대한 화이트리스트 저장
    • 이걸로 시빌어택을 막을 순 없지만, 프론트단에서 편리한 보안 기능을 제공합니다. geth의 Authentification 기능과 포지션이 유사할 수 있다고 생각하면 될 것 같습니다.
• 🥩

airbloc python node와 같은 label 시스템을 사용했으면 좋겠습니다.

Purpose

geth의 기본 클라이언트 포트인 8545번 포트를 스캔해서 막혀있지 않은 노드들의 자산을 빼돌린 사건이 있었음.
살펴보니까 geth에는 기본 인증 기능이 없어서 바깥쪽에 레이어를 하나 더 감싸야 함.
그런데 이걸 해야되는지 모르는 사람들이 수두룩하기 떄문에 우리가 만들어줘야 할 것 같음.
왜 모르는 사람들이 많냐고 생각하냐면 https://thehackernews.com/2018/06/ethereum-geth-hacking.html 이거 참고 털린 돈이 "조금" 많음

• 신뢰 가능한 input data
  • order시에 input signature를 넣는다 (1)
  • 아! 몰라! 그냥 order넣을때 같이 input data도 넣어! (2)

1. golang에서 abi, address, input data만 가지고 contract call을 하기
2. solidity 노가다