한글 프로그래밍 언어인 '소나무 언어'의 설계 과정에서 solidity 계약서에서 어떠한 문법이 주로 사용되며, 한글 언어로 변환되면서 solidity 언어의 어떤 부분이 간소화될 수 있을지 등을 도출하기 위해 이더리움 네트워크에 배포되어 있는 기존 계약서를 분석하고 한글 계약서와의 비교를 수행했다.
1. solidity contract 분석
1-1. 중고거래 contract
contract escrow {
// contract 생성자
constructor(uint _price) public payable {
seller = msg.sender; // contract를 생성한 사람을 seller로 지정
price = _price; // contract 생성 시 물건 값을 받아 price에 저장
pay = price * 2; // 사기 방지를 위해 물건 값의 2개를 받는 것으로 추정
state = "start"; // contract 상태
number = 0; // 송장 번호
emit const1(); // 생성 후 이벤트 emit
}
// 구매자가 판매자에게 구매를 요청
function purchase_request() public payable
{
// 구매자가 물건 값의 2배를 contract에 송금했는지, state가 'start'인지 확인
require(msg.value == pay && equal(state,"start"));
// buyer(구매자)을 구매 함수의 호출자로 설정
buyer = msg.sender;
// 상태 변경
state = "processing";
emit p_request();
}
// 송장 번호 입력
function input_number(uint _number) public
{
// 송장 번호는 판매자만 입력 가능
require(msg.sender == seller);
// 송장 번호를 입력
number = _number;
}
// 구매자가 물건 수령 완료 시
function buyer_receive(uint _number) public payable
{
// 함수의 호출자가 구매자인지, 상태가 'processing'인지 확인
require(msg.sender == buyer && equal(state, "processing"));
// 판매자가 송장 번호를 입력했을 시, 실제 수령한 물건의 송장 번호와 일치하는지 확인
if(number !=0){require(number == _number);}
// 상태 변경
state = "success";
// 물건 값 (price) 만큼을 구매자에게 재송금 (예치금 수령)
buyer.transfer(price);
// pay - price, 즉, 물건 값(현재 contract의 잔액)을 판매자에게 송금
seller.transfer(address(this).balance);
emit b_receive();
}
// 거래 중도 취소
function transact_cancel() public payable
{
// 상태가 'start'인 경우
if(equal(state,"start")) {
// 혹시 남아있는 contract의 잔액을 판매자에게 송금
seller.transfer(address(this).balance);
}
// 상태가 'processing' 인 경우
else if(equal(state,"processing")) {
// 구매자가 입금한 금액 환불
buyer.transfer(2*price);
// 혹시 남아있는 contract의 잔액을 판매자에게 송금
seller.transfer(address(this).balance);
}
// 상태를 거래 취소로 변경
state = "cancel";
emit t_cancel();
}
출처 : https://github.com/nowis530am/blockchain-solidity/blob/master/escrow.sol
중고거래 contract도 실제 네트워크에 배포되어있는 것을 찾고 싶었으나 딱 중고거래에 맞는 DApp은 찾기가 쉽지 않아 부산대학교에서 졸업 프로젝트로 만들어진 중고거래 DApp의 소스 코드를 깃헙에서 발견해 분석에 사용하였다. 몇 개의 contract를 분석하다보니 어느정도 패턴이 보였는데 크게 아래와 같은 함수들로 구성되어 있음을 확인할 수 있었다.
1. 판매자의 contract 등록
2. 구매자의 구매 (예치금 전송)
3. 물건 발송
4. 물건 수령 후 예치금 분배
5. 구매 취소 기능
1-2. Shop.vol
contract Shop {
using SafeMath for uint256;
address public owner; // 이 contract를 배포(deploy)한 사람의 주소를 기록
mapping (uint256 => bool) purchasedTickets; // 각 티켓의 구매 여부를 기록?
constructor() {
// contract가 생성될 때 생성한 사람의 주소를 owner에 저장함
owner = msg.sender;
}
function buyItem(uint256 _price, uint256 _appFeePercentage, address payable _seller, uint256[] memory _voucher_ids) public payable returns(bool){
// 실제 전달된 금액(msg.value)이 전달하라고 제시된 금액(_price)보다 적은 경우 오류
require(msg.value >= _price, "You should send over price");
// _seller에게 _appFeePercentage를 제외한 금액을 전달함 => 나머지 금액은 contract에 저장?
_seller.transfer(msg.value.mul(100 - _appFeePercentage).div(100));
for (uint256 i = 0; i < _voucher_ids.length; i++) {
// 구매하려는 티켓의 id가 _voucher_ids에 포함됨?
// 구매한 티켓의 bool 을 true로 변경
purchasedTickets[_voucher_ids[i]] = true;
}
return true;
}
// 수수료
function withdraw() public returns(bool){
require(msg.sender == owner, "You are not owner of the contract");
address payable _owner = payable(msg.sender);
_owner.transfer(address(this).balance);
return true;
}
// contract의 owner를 변경
function setOwnerShip(address _newOwner) public returns(bool) {
require(msg.sender == owner, "You are not owner of the contract");
owner = _newOwner;
return true;
}
// 주어진 _voucher_ids 배열에 저장된 id에 해당하는 ticket이 소유권이 있는 티켓인지 확인하여 반환
function contains(uint256[] memory _voucher_ids) public view returns (bool){
bool contained = true;
for (uint256 i = 0; i < _voucher_ids.length; i++) {
if (!purchasedTickets[_voucher_ids[i]]){
contained = false;
}
}
return contained;
}
}
출처 : https://etherscan.io/address/0xa42d7d8ea9f4bbe1218f0660fa3217c923f63c09#code
위의 예시는 이더리움 네트워크에 배포되어 있는 티켓을 거래할 수 있는 solidity DApp이다. 눈에 띄는 것은 안전한 거래를 위해 SafeMath 라이브러리를 (코드는 생략하고 첨부함) 사용했다는 점이다. 이 라이브러리는 unsigned int의 overflow를 방지해주는 역할을 한다. 함수의 구성은 판매 대상이 티켓으로 한정되었다는 점을 제외하고는 1-1의 중고 거래 코드와 비슷한 구조를 갖는 것을 확인할 수 있었다.
2. 기존 서면 계약서와의 비교
서면 계약서와의 비교를 위해 중고차 거래 계약서와 구매 & 공급 계약서를 찾아보고 포함된 항목들을 작성해보았다.
2-1. 중고차 거래 계약서
매매할 자동차의 표시 | 1. 등록 번호 2. 차대 번호 3. 차종 4. 차명 |
계약 내용 (약정 사항) | 1. 전체 매매금액 2. 계약금과 지블 일시 3. 중도금과 지블 일시 4. 잔금과 지블 일시 5. 그 외 계약 사항들 ex) 공과금부담, 하자책임, 사고책임, 등록지체책임 등등 |
특약 사항 | ex) ‘명의 이전은 ~~까지 완료한다.’ |
계약당사자 및 입회인 인적사항 | 1. 주소 2. 주민등록번호 3. 성명 |
2-2. 구매 & 공급 계약서
매수인, 매도인 인적사항 | 1. 주소 2. 사업자 등록번호 3. 대표 이사 성명 |
매매 관련 계약 사항 | 1. 매매 계약일 2. 매매 물건명 3. 매매 대금 4. 물건 인도 장소 5. 납품 기간 6. 대금 지급 기일 |
특약 사항 | 1. 지연 배상금 |
기타 사항 |
위와 같은 내용들을 찾아보다보니 우리가 수행하는 프로젝트는 DApp을 만드는 것이 아니라 DApp 제작에 사용되는 언어를 만드는 것이기 때문에 한글 계약서의 내용을 어떻게 DApp으로 구현할까? 보다는 어떠한 항목들이 계약서에 포함되며 이것이 어떻게 solidity contract로 구현되는지 그 관계를 살펴보는 과정이었다고 생각한다.
이제 이러한 내용을 인지한 상태로 실제로 언어를 설계하면서 개발 환경 등을 결정해나갈 시기라는 생각이 들었다.
'프로젝트 > 졸업 프로젝트' 카테고리의 다른 글
소나무 언어에 다른 기술 접목 아이디어 (0) | 2022.04.12 |
---|---|
이해당사자 특정 및 문제 상황 정의하기 (0) | 2022.03.27 |
인프런 '블록체인과 솔리디티' - 솔리디티 (0) | 2022.03.27 |
인프런 '블록체인과 솔리디티' - 블록체인 (0) | 2022.03.27 |
도출된 아이디어 덧붙이기 (0) | 2022.03.27 |
백엔드 개발을 공부하고 있습니다.