# Smart Contract Generation Assisted by AI-Based Word Segmentation
## 2 Related Works  
### Smart Contract Generation  
Before discussing smart contract generation, we briefly introduce the concept of the smart contract. The smart contract was originally proposed by [PERSON] [8], who considered that legal contract clauses can be embedded into computer hardware and software, such that obligations of the contract were automated and bleach-proof. In this sense, a smart contract was an extension of electronic contracts (e-contracts) that emphasized automatic contract execution [9]. Meanwhile, the legal binding concept in [PERSON]'s design was also elaborated in many follow-up works. For example, the Ricardian Contract was a legal, digital, and verifiable contract system for issuance with the capability for human understanding and code execution [10]. Smart contract templates were proposed to convert legal documents into program codes in [11]. Borrowing the concepts of smart contract codes and smart legal contracts from [12], the authors argued that the operational aspect of a legal contract can always be automated as smart contract codes. The extracted operational parameters and the legal prose were the core of a smart contract template. Although [PERSON] conceptualized many aspects of the smart contract in [8] and related research, the smart contract remained a theoretical artifact until the emergence of blockchain in the past decade. Blockchain-based smart contracts were collections of agreements written in code scripts and deployed on blockchain platforms, which were automatically executed upon the arrival of mandatory data [13]. A blockchain smart contract can be written in two types of high-level programming languages: imperative and declarative languages [14]. Imperative languages were more common in existing blockchain smart contract systems. Although they can implement fairly complex operations, they were not straightforward for human reading and understanding. Meanwhile, declarative languages were like rules and logic, so they are more intuitive for human interpretation. Various studies had advocated its adoption into the existing blockchain ecosystem [9; 14]. Smart contract generation is the initial step of the life cycle of a smart contract consisting of generation, deployment, and execution [5; 9]. Four types of generation approaches had been observed in the literature: arbitrary constraints to the smart contract, formally specified constraints to the smart contract, business processes to the smart contract, and legal agreements as smart contracts. Their differences lie mainly in the choices of smart contract representations and the levels of formalism. _Arbitrary Constraints to Smart Contracts_ (AC-SC) are the most primitive type of smart contract generation, relying on a programmer to read and understand the smart contract requirements in arbitrary formats, then design, implement, and test the corresponding smart contracts. Differently, _Formally specified Constraints to Smart Contracts_ (FC-SC) can achieve (partially) automatic smart contract generation, because the contractual constraints were usually presented in a formal and structured format, e.g., via domain-specific ontologies and semantic rules [15]. Therefore, well-defined transformation rules, such as a domain-specific language (DSL) [16], can be applied. The generated results were usually smart contract skeletons that still depended on the manual implementation of the core logic. These two types of approaches usually produce smart contracts written directly in a programming language. By contrast, _Business Processes to Smart Contracts_ (BP-SC) and _Legal Agreements to Smart Contracts_ (LA-SC) utilized logical smart contracts as an intermediate representation, achieving the separation of a smart contract's specification and implementation. The smart contracts were generated from the constraints of business process [17; 18] and legal agreement [11; 19], respectively, which were often too complex to be directly encoded as program codes but suitable to be described logically.