在本文中，我将介绍汽车共享智能合约的基本知识，其自主权由几个人共享。该车将可供任何第三方租用当天，然后，一旦租赁期结束，它将分配其收益给业主。
关于这款智能汽车及其合同的一些假设和考虑因素，对于这种分析，我将做出一些假设，这将简化智能合约的逻辑。
首先，我将假设汽车以某种方式运行一个允许其签署交易的完整节点。汽车将拥有一个帐户/地址，该帐户/地址将成为与不同用户交互的智能合约的“所有者”。
汽车的所有权将非常简单。首先，车主从一开始就得到一辆车，假设付款是在经销商处进行的。然后，每个车主拥有相同份额的汽车。最后，我们不会处理复杂的决定，因为这篇文章会非常广泛。
最后，我还假设汽车以某种方式为用户提供了一些能够与智能合约互动的界面。此外，汽车可以安排稍后调用某些功能，例如调用24小时后结束租赁期的智能合约中的功能。此外，我假设用户拥有能够与区块链交互的设备，例如支持web3的浏览器。
这些假设的目的是使智能合约尽可能简单，同时尽可能多地为汽车本身做出决策。我很确定在现实世界中可能会出现以下情况，但可能不是最佳解决方案。无论如何，请随意讨论更好的方法或指出您认为在现实世界中根本不起作用的合同部分。
智能合约
以下不是完整的代码，而是其中最重要部分的亮点。（具体源代码在公众号有展示）
初始化汽车智能合约
让我解释每个状态变量和SmarCar合约的构造函数：
carSigner：这是代表汽车的帐户。正如我之前提到的，汽车应该运行自己的节点，该节点将签署它需要执行的事务。这是将部署汽车合同的帐户。在现实生活中，我想象制造商设置汽车节点和帐户。我们假设经销商和制造商都无法访问此帐户的私钥。我想说的是：汽车将需要执行合同功能，而这样做的唯一方法就是汽车本身是一个外部拥有的帐户，可以与智能合约进行通信而不依赖于人机交互。
carValue / LicensePlate：这是在部署汽车合同时应提供的值。 LicensePlate可用于识别汽车（我们不会进行任何检查以确保它是唯一的）并且carValue设定了车主为其支付的价格。我们没有使用carValue，但我们可以拥有一个功能，允许车主将他的汽车份额出售给其他人，carValue /车主可以用来建立基本价格。
owner / MAX_OWNERS = 100：Owners是一个数组，用于保存汽车所有者的地址。 MAX_OWNERS是一个常数，它将限制汽车拥有的车主数量。
ownersBalance / balanceToDistribute：ownersBalance将用于存储每个所有者可用于提取的待处理余额。当汽车开始付费乘车时，它将以自己的余额存储收到的以太币，然后当乘车结束时，它将以相等的部分分配给每个所有者，以便所有者手动提取其余额。
carShares / INITIAL_CAR_SHARES = 100：carShares用于存储每个所有者拥有的汽车数量。目前，我们这样做是为了让每个车主拥有相同的汽车部件，但是可以这样做，这样有人可以拥有50％的汽车，其他10人拥有5％的汽车。这也必须影响收益的分配方式，以便按比例完成。
currentDriverEntity / currentDriveStatus：这些变量是状态机的一部分，它将控制汽车当前正在做什么。例如，如果它被驱动，合同不应该允许其他人租用它。我们还使用DriverEntity来跟踪汽车当前正在做什么 - 它是否适用于优步？它是否已经租了一天？是其中一位业主使用它吗？这也引发了一些关于汽车应该如何自主以及如何确定它应该做什么的问题，我将在本文末尾讨论，但这也超出了本文的范围。
currentDriverAddress/currentDriveStartTime/ currentDriveRequiredEndTime：这些变量跟踪当前租用汽车的人，租赁期开始时以及何时结束（租赁期开始后24小时）。 currentDriveRequiredEndTime用于确定租用汽车的人是否在指定的租赁期内退回了汽车。暂时我们只是记录这个，但如果条件不满足，可以采取一些行动。
CarInternals：我们还没有做任何事情，但这可以用来跟踪汽车的内部。它需要燃料吗？什么是电池状态？它需要换油吗？冷却液？如果这些内部任何一个处于临界水平，它应该怎么办？
SmartCar构造函数：这个合同的构造函数非常简单。我们只是设置一些变量的初始状态，最重要的是分配carSigner。
本文转载公众号：区块链研究实验室，具体源代码请参考公众号。