我有小广播，你要听我说：小姐姐辛苦翻译分享，心疼小姐姐的转载总可以注明来路吧！！如遇币豪们，文章下面有小姐姐的打赏地址，收基于ERC-20的各种币，一个都不嫌弃哦！
二 LENDROID FROM FOUR USER JOURNEYS
A more comprehensive and effective understanding of the protocol can be achieved when approached from the user journeys of four key actors.
2.1. THE LENDER
Analogous to the Maker from the 0x protocol [6], the lender broadcasts the loan-offer to all decentralized exchanges (off-chain action). Of the different types of accounts within the Lendroid Smart Contract system, the Funding Account is available to the lenders to deposit funds into and offer loans from. Each loan offer is a data packet called the offer object
containing the terms of the loan, offer parameters, and an associated ECDSA signature. The loan terms and parameters are concatenated and hashed to produce a 32 byte-long Keccak SHA3 signature called the offer-hash. The lender signs this offer-hash with their private key to produce the ECDSA signature. As discussed in section 1, it is imperative that the interests of the Lender - who contributes to the shared liquidity pool - are protected. This is enabled by empowering the Lender to define key parameters within the offer object.
2.1.1. Defining the Offer Object
Off chain, the Lender defines the offer object with a range of parameters [See Table 1], key among them
a. Loan Amount and Interest Rate: The Lender defines the offer amount (token offered and number of units of the token) and sets the interest to be calculated on a daily basis.
b. Loan Expiration Period: The validity of the loan from the time it is availed. On expiry, the loan is called in and, should the borrower so choose, rolled over with another loan.
c. Offer Expiration: The validity of the offer itself. Based on the demand for a token, a Lender might want to change his offer to reflect a different interest rate or number of token units. Setting a prudent expiry time for the offer allows for this flexibility, without having
go on-chain.
Though not part of the offer object as currently envisioned, automatic renewals of loans too can be explored.
It is important to note that every loan also requires some LST for initialization. To lubricate the inherent processes, the lender deposits some LST meant for the Relayer at the end of the loan period. Some he deposits for the Wrangler in the event that it was he who identified the Margin Account at liquidation level and helped close the loan. The LSTs required for these processes are locked in at the time of initiation. If there is not enough LST for these processes, the loan is not initialized.
2.1.2. Cancelling the Loan Offer
A loan offer is deemed invalid, and therefore is cancelled, in the following cases: a. If a loan offer is availed after its expiration period: In this case, the Loan Smart Contract recognizes that the offer cannot be availed anymore, and triggers an event indicating to all Relayers that the loan with the corresponding hash is invalid. It is in the Relayers’ best interests to not display expired loans in the first place and, even if they do, they have the option to listen in on the Loan Offer Cancelled event from the Loan Smart Contract.
b. If a Lender decides to cancel an offer that has been left unavailed and unfilled: In this case, the lender can call the Loan Smart contract’s Cancel Loan function which further triggers the Loan Offer Cancelled event from the same Smart Contract, thus notifying all listening Relayers. Cancelling a loan offer is a fallback mechanism and costs gas. Therefore, it is in the best interests of the lender to set a suitable Expiration Period on the offer to avoid on-chain transactions.
2.2 THE RELAYER
The Relayer is the first point of contact for both lender and trader on the Lendroid protocol. Off chain, this entity effectively takes up the liquidity related functions of an exchange in a wholly decentralized manner. The one significant addition to the Lendroid Relayer over its 0x counterpart is the management of loan offers. Relayers provide an interface, and manage order books and offer books. They are key to creating the shared global lending pool.
2.2.1. Interface
As actors that operate almost entirely off-chain, the Relayer’s potential for creating a smooth, fast, user experience, is limitless. Available interfaces today offer an increasingly sophisticated dashboard, with periodic upgrades in granularity, of data native to the protocol, as well as relevant external information from the market, to help lenders and margin traders make more informed decisions. Loan offers are captured and offered as part of this interface. The richness of the information on display depends on the depth that a particular Relayer chooses to showcase. Without exception, every Relayer has complete access to the shared lending pool – the collective of loan offers recorded with not just one particular Relayer, but with the entire community of Relayers on the protocol. Relayers can also offer APIs to facilitate programmatic access to offer books. With access to the entire lending pool, and with off-chain speed and flexibility at their disposal, Relayers can maintain liquidity and create an interface that encourages patronage.
2.2.2. Bookkeeping
The same off-chain advantage in interface extends to the bookkeeping function of the Relayer as well. With computational power unbridled by on-chain lags and costs in gas, a Relayer can maintain Offer Books in a real-time, seamless manner. The Relayer is incentivized with a fee in the Lendroid Support Token (LST) for recording and relaying the loan offer. A fee is paid by the Lender and, when the loan is availed, by the borrower/margin trader as well. Attracting liquidity into the platform, the Relayer is paid only when a loan is availed, and closed properly. The Relayer is able to match and offer with an ask even if it originated with another Relayer. Despite the incentive, and the fact that the Relayer has access to the entire shared lending pool, the protocol remains trust independent because of two key 0x-inspired characteristics [6], written into the protocol itself.
a. Relayers cannot execute transactions on behalf of the Lender or the Margin Trader. They can only recommend an ideal offer.
b. A clear fee structure when a loan is availed. The Relayer with whom the offer was recorded is paid by the Lender, and the same Relayer is paid by the Margin Trader once the loan is paid back.
2.2.3. A Global, Shared Liquidity Pool
Due to the inherent trust-independence of the protocol, access to loan offers is not limited to any one Relayer or a particular set of Relayers on Lendroid. As an extension, all the lenders and the Margin Traders on the platform contribute to liquidity in the ecosystem. As Figure 3 illustrates, a lender is free to engage with any Relayer on the protocol. Irrespective of who they record the loan offer with, it goes into the shared lending pool. When catering to the Margin Trader, a Relayer is free to recommend loan offers received from any Relayer. In the interest of providing a ‘sticky’ experience that could make him the Primary Relayer, it is in his best interest to connect the Lender or Margin Trader to the most ideal offer.
共享贷款池
2.3 THE MARGIN TRADER
On Lendroid, the Margin Trader enjoys leveraged lending in a uniquely decentralized
environment. He deposits collateral, avails the loan offered by lenders and engages in margin trading/short selling. He opens a margin account, within which he is free to change positions or add collateral. He can withdraw his collateral or liquidate his Margin Account when there are no loans owed. Here’s how those actions play out, broadly.
2.3.1. Locking in Collateral
Lendroid is compatible with any ERC20-based token. This gives the Margin Trader a high level of flexibility with respect to the nature of collateral he can deposit against a loan. A Margin Trader is free to deposit not just one kind of collateral in a token of his choice, but multiple kinds of ERC20-based tokens at the same time, in the same margin account. However, the support for a token has other considerations besides compatibility alone. In what is envisioned as a community-driven governance model, the protocol will add or remove support for a token based on the current volatility of the token. If the Margin Trader finds that the health of the margin account has dipped, he can add collateral at any time before the liquidation process is initiated on his account.
2.3.2. Availing a Loan
As illustrated in section 2.1, a Margin Trader can avail a loan through his Relayer. It is in the interfacer provider’s interest to connect him to the ideal offer. Offers are signed by the respective Lenders who made them are available with the Relayer. When a Margin Trader finds one that is suitable for his needs, he calls the availLoan function on the Loan Smart Contract, by including the offer object in the function call. Using the ecrecover function, the smart contract will then verify that the signature is valid and, based on the timestamp, that the offer has not expired. The Smart Contract also checks the Lender’s funding account to make sure there are sufficient funds to carry out the offer. Once ratified, the funds are credited to the Trader’s Margin Account and debited from the Lender’s Funding Account.
2.3.3. The Margin Account
The Margin Trader stakes LST when opening a Margin Account. This stake is refundable, when the Trader closes trade positions and repays the loan. However, in case the account drops below the liquidation level, the deposit becomes a bounty for the Wranglers.
In the Margin Account, neither the collateral nor the positions can be withdrawn without honouring the terms of the loan. However, a Margin Trader is free to manipulate both elements at any time to maximize returns. He can top up collateral in a flagging account, and calibrate his positions with the help of decentralized order book protocols.
illustrates part of the user journey of a Margin Trader. His relationship with the Margin Account, dynamic and protected at the same time, can be understood in three states.
In Figure 4a, there’s the Margin Account on the extreme right, which contains the capital he borrowed for the trade, and the possibility of creating trade positions out of available funds.
In Figure 4b, we see that the Margin Trader has calibrated his trade positions. This intent is recorded on-chain, and executed using a decentralized order book protocol. Lendroid is capable of integrating with multiple order book protocols, including 0x, Kyber, Omega, and others. When positions need to be updated or rearranged, the Margin Trader can delegate the function to the most liquid order book protocol in the ecosystem.
In Figure 4c, we see that at the end of a trading session, the trade positions have done well for the Margin Trader and a profit has been accrued over and above the borrowed capital.
2.3.4. Closing a Loan
The loan terms are specified by the Lender right at the beginning, when the offer is made. There are three scenarios in which the loan is closed. The first is the scenario described in Figure 4c. The Margin Trader has made a successful trade and is able to close the loan, repaying it without incident. Alternatively, the term of one or many loans might be close to expiry even when the Margin Trader is not ready to unwind his trade positions. Monitoring this can be delegated to incentivized actors called Wranglers, who will help replace or ‘roll-over’ an expiring loan with a fresh one. Though not built?into the protocol, this specific function is a logical extension of a Wrangler’s primary role – that of monitoring the margin account. In the third scenario, a Margin Account underperforms and warrants immediate action. A Wrangler has identified the account. The Wrangler then repays the loan to the Lender himself, and also triggers an auction of the Margin Trader’s collateral and positions. A fourth and less likely scenario is a Black Swan event, where a Margin Account has been left unattended by Wrangler and Margin Trader and, for enough time to cause damage, by the Lender himself. In such a case, the Lender can call in his loans and as a result will take over and choose to withdraw the collateral and trade positions as a compensation.
2.4 THE WRANGLER
The Wrangler is an entity conceptualized for the Lendroid ecosystem. One of two incentivized actors within the protocol, the Wrangler is intended to perform a computationally intensive role: that of monitoring the Margin Accounts. By monitoring and ‘Wrangling’ terminal accounts (at liquidation level), the Wrangler maintains the general health of the ecosystem, while also protecting the interests of the Lenders. However, the applications of such processing power spill beyond the requirements of the protocol, and can begin to enhance the experience of the other participants.
2.4.1. Margin Level Monitoring
Every on-chain event is broadcast on the protocol. It is this broadcast that the Wrangler tunes into. The Wrangler keeps tabs on each development: from the creation of a Margin Account, to every state change in position, adding of collateral, etc until the account is liquidated. Whenever there is a change in the state of a Margin Account as a result of calling a function from the Lendroid Smart Contract system, the Account Smart Contract triggers an event notifying and specifying the function name and the corresponding Margin Account.
For accurate and contextual computation, the Wrangler needs both on-chain and off-chain data.
It is important to note that margin monitoring, recognized as an aspect of risk management, was hitherto performed by a centralized exchange to protect the Lender’s interests and the market integrity. Conventional exchanges would make what is known as a ‘margin call’ – an actual phone call to the trader, asking him to deposit additional funds – when the account dipped below a certain percentage of leverage [8]. Since the concept of a margin call is improbable on the blockchain ecosystem, the Wrangler’s role becomes all the more vital for the health of the market. This is why the Wrangler’s role, powered by computational capability, is incentivized in innovative ways. For instance, as seen in 2.3.4., a Wrangler can be delegated – for a fee by the Lender – to not just monitor the Account, but also help with rolling over an expiring loan with a fresh one. The Wrangler picks up a bounty when he ‘wrangles’ an Account at liquidation level. He also stands to earn the right to the MarginTrader’s collateral or his trade positions, when he triggers an Auction.
2.4.2. Triggering an Auction
Having identified what he deems a terminal Margin Account, the Wrangler already stands to win the bounty attached to it. However, there is more at stake. The Wrangler cannot withdraw the collateral or liquidate the positions any more than the Margin Trader can. He triggers an auction, a competitive process, which demands that the claim is verified by the Lendroid Smart Contract system and also by other competing Wranglers via independent sources of market information. The actual auction process is described in a subsequent section.
-------------------------------------------------------------------------------------------
第二部分：Lendroid架构流程中的四个主要角色
四大角色： 贷方，中继者，保证金交易者，牧马人（监督员）
从四个关键角色的用户体验中，可以实现对协议更全面和更有效的理解.
2.1 贷方
类似于来自0x协议的做市商，贷方向所有分步的交易所广播贷款（链下行为）。在Lendroid智能合约系统中不同类型的账户中，资金账户是可供贷款人存入资金并提供贷款。每个贷款要约都是一个数据包，叫做要约对象，包含贷款条件，要约参数和相关的ECDSA签名（椭圆曲线数字签名算法）。 贷款条款和参数连接在一起并散列，产生32字节长的基于Keccak 的SHA3签名，称为offer-hash。 贷方用私钥对这个offer进行签名，生成ECDSA签名。
正如第一部分所讨论的那样，贷款人的利益（对共同流动资金池的贡献）是受到保护的。 这是通过授权贷方在要约对象中定义关键参数来实现的。
（技术点：SHA3 （加密算法C语言测试代码（基于Keccak算法））
2.1.1 定义链下要约对象
贷方用一系列参数定义offer对象[见表1]，其中的关键字
a.贷款金额和利率：贷方定义要约金额（提供的代币和代币单位数量），并设置每天计算的基本利息。
b,贷款到期期限：贷款从有效期起的有效期。 到期时，贷款被召回，如果借款人愿意的话，可再借另外一笔贷款。
c.要约截止期：根据要约的有效性。基于对代币的需求，贷款人可能想要改变他的要约以反映不同的利率或代币的单位数量。无需在链上，为要约的灵活性设置谨慎的到期时间。
虽然不是目前设想的要约对象的一部分，但也可以探索自动续借贷款。
需要注意的是，每笔贷款都需要一些LST进行初始化。为了运行固有的过程，贷款人在贷款期结束时，为中继者存放一些LST。 一些LST是为牧马人存入，牧马人负责识别保证金账户的清算水平并帮助关闭贷款，这些过程所需的LST在启动时被锁定。 如果这些流程没有足够的LST，则贷款不会被初始化。
2.1.2 取消贷款要约
在下列情况下，贷款要约视为无效因此将被取消：
a. 如果贷款要约在到期后有效：在这种情况下，贷款智能合约确认不能再使用该要约，并触发一个事件向所有中继者指示该贷款与相应的散列无效。
b. 在Relayer的最佳利益中，不显示过期的贷款，即使他们这样做，他们也可以选择从贷款智能合约中获知贷款要约取消的事件。
2.1 中继者
中继者是Lendroid协议上贷款人和交易者的第一个接触点。在链下，该实体以完全散的方式有效地承担了交易所的流动性相关职能。与0x相比，Lendroid中继程序的一个重要附加部分是贷款要约的管理。中续者提供一个接口，并管理订单和提供订单簿。它们是创建共享的全球贷款池的关键。
作为几乎完全脱离链的运行角色，中继者创造出流畅、快速、用户体验的潜力是无限的。如今，可用的接口提供了一个日益复杂的按钮（仪表板），定期更新协议中的数据，以及来自市场的相关外部信息，以帮助放款人和保证金交易者做出更知情的决定。
2.2.1 接口
贷款要约被捕获并作为此接口的一部分提供。显示信息的丰富性取决于特定中继者选择展示的深度。无一例外，每个中继者都可以完全访问共享的贷款池---贷款提供的集体记录不仅由一个特定的转接器记录，而且与整个协议中继者社区记录在一起。 中继者还可以提供API，以方便编程访问。 有了进入整个贷款池的机会，加上脱链的速度和灵活性，中继者可以保持流动性，并创建一个鼓励光顾的接口界面。
2.2.2. 记账
界面中同样的链下优势也扩展到了中续者的簿记功能。 计算能力不受链上滞后和费用成本的影响。一个中继者可以实时，无缝的方式维护要约簿。
中继者记录和转播贷款要约获得LST的代币作为交易费用。 贷方支付一定的费用，并在贷款被利用时借款人/保证金交易者也支付费用。吸引流动性进入平台，中继者只有在贷款被有效使用并且合理关闭是才被支付。
中继者甚至可以匹配从另外一个中继者发出的请求。通过询问进行匹配， 尽管有激励机制，并且中继者也可以访问整个共享借出池，但协议仍然是信任独立的，因为两个秘匙的0x引发的特性写入了协议本身。
a.中继者不能代表贷款人或保证金交易者执行交易。他们只能推荐一个理想的订单。
b.当贷款被利用时，有明确的收费结构。 记录订单的中继者由贷款人支付，一旦偿还贷款，同一个中继者由保证金交易人支付。
2.2.3. 全球共享的资金池
由于协议固有的信任独立性，获得贷款的机会不限于任何一个中继者或者一个特定的Lendroid中继者。作为一个延伸，平台上的所有贷款人和保证金交易者都对生态系统的流动性做出了贡献。
如图3所示，贷款人可以自由地与协议上的任何一个参与者进行交流。无论他们将贷款提供给谁，都会进入共享的贷款池。迎合保证金交易者时，一位中继者可以免费推荐从任何一位中继者处获得的贷款。 为了提供一个“粘性”的体验，可以使他成为主要的互动者，将贷款人或保证金交易者撮合到最理想的报价，并符合他的最大利益。
资金池
2.3保证金交易者
在lendroin上，保证金交易者在独特的分步式的环境中享受杠杆借贷。他存放抵押品，利用贷款人提供的贷款，从事保证金交易/卖空。他开设了一个保证金账户，在这个账户中，他可以自由更换头寸或添加抵押品。在没有贷款欠款的情况下，他可以撤回抵押品或清算其保证金账户。
2.3.1. Locking in Collateral 锁定在抵押品
Lendroid兼容任何基于ERC20的令牌。 这使得保证金交易者在抵押贷款的抵押品性质方面具有高度的灵活性。一个保证金交易者可以自由存取他所选择的代币中的一种抵押品，但可以同时在相同的保证金账户中存入多种基于ERC20的代币。 但是，除了兼容性之外， 在所设想的社区驱动治理模式中，对代币的支持还有其他一些考虑因素。该协议将基于代币的当前波动性来添加或移除对代币的支持。如果保证金交易者发现保证金账户的健康状况已经下降，他可以在清算过程开始之前的任何时候添加抵押品。
2.3.2.有效贷款
如第2.1节所述，保证金交易者可以通过他的中继者获得贷款。接口提供商致力于匹配一个理想的订单。 订单由相关贷款人签署，让他们可以被中继者使用。
当一个保证金交易者发现一个适合他的需求的要约时，他通过该函数调用中包含该提供对象来调用贷款智能合约上的有效贷款功能。使用ecrecover函数，智能合约将验证签名是否有效，并根据时间戳 ，确定该要约尚未到期。
智能合约还检查贷方的资金账户，以确保有足够的资金来执行该要约。 一旦批准，资金将记入保证金交易者保证金账户，并从贷方资金账户中扣除。
2.3.3. 保证金账户
开立保证金账户时，保证金交易者持有LST。当交易者关闭交易头寸并偿还贷款时，该股权可退还。但是，如果账户低于清算水平，存款成为了牧马人的赏金。 在保证金账户中，如果不履行贷款条款，抵押品和头寸都不能被撤回。然而，保证金交易者可以随时操纵这两个要素，以获得最大的回报。他可以在标记帐户中加入抵押品，并在分散的要约簿协议的帮助下校准其头寸。
图4:部分保证金交易者的用户流程。 他与保证金帐户的关系是动态和同时受到保护，可以理解为三个状态
a.最高权限的保证金帐户包含他为交易借入的资金，以及可用资金之外的可能创建交易的头寸的。
b.我们看到保证金交易者已经校准了他的交易头寸。 这个意图被记录在链上，并且使用分散的要约簿协议来执行。Lendroid能够集成多个要约簿协议，包括0x，Kyber，Omega等。 当头寸需要更新或重新安排时，保证金交易者可以将该功能委托给生态系统中最具流动行的要约簿协议。
c.我们看到在交易时段结束时，交易头寸对于保证金交易者来说表现良好，除了借入资本之外，还有一笔利润。
2.3.4. 关闭贷款
贷款条款在出价开始时由贷方指定。 贷款关闭有三种情况。
首先是图4c中描述的场景。
保证金交易者已经成功交易，能够结清贷款，无偿地偿还。 另外，即使保证金交易者没有准备好解除其交易头寸，一笔或多笔贷款的期限也可能即将到期。监督这个的任务可以委派给被称为牧马人（监督者）的激励参与者，他们将帮助替换或“回滚”新到期的贷款。虽然没有纳入协议，但这个特定功能是牧马人主要角色的合理扩展 - 监控保证金账户。 在第三种情况下，保证金账户表现不佳并需要立即采取行动。牧马人已经确定了账户。 然后，牧马人自己向贷款人偿还贷款，并触发拍卖保证金交易者的抵押品和头寸。
第四种可能性较小的情况是黑天鹅事件，其中一个保证金账户在牧马人监督者）和保证金交易人员无人看管的情况下，并且有足够的时间由贷方自己造成损害。在这种情况下，贷款人可以收回他的贷款，因此将接管并选择撤销抵押品和交易头寸作为补偿。
2.4THE WRANGLER 牧马人（监督者）
是Lendroid生态系统概念化的实体。 在协议中的两个激励角色之一，牧马人（监督者）执行是一个计算密集型的角色：监控保证金账户。牧马人（监督者）通过监控和“终结”终端帐户（在清算水平）维护生态系统的总体健康状况，同时保护贷款人的利益。然而，这种处理能力的应用超出了协议的要求，并且他可以提升（增强）其他参与者的经验。
2.4.1. Margin LevelMonitoring 保证金水平监测
在协议上的每个链上交易事件的广播。 由牧马人（监督者）调入广播。 牧马人（监督者）密切关注每一个发展状态：从保证金账户的创建，到每个头寸的变化情况，，抵押品的增加等，直到账户被清算。
每当由于从Lendroid智能合约系统调用一个功能函数而导致保证金账户状态发生变化时，账户智能合约会触发一个事件通知和指定功能函数名称和相应的保证金账户。
下面代码突出了牧马人在监控保证金账户时所执行的一系列离线和在线计算。
为了准确和发现的情况计算，牧马人（监督者）需要链上和链下数据。重要的是要注意保证金监控一直是被作为风险管理的一个方面，迄今为止由集中交易所进行，以保护贷款人的利益和市场的完整性。传统的交易所会进行所谓的“保证金追缴” -当账户低于一定的杠杆比例时， 一个真正的电话打给交易者，要求他存入额外的金额，，由于追加保证金概念是不可能在区块链生态系统中，牧马人的角色对于市场的健康变得更加重要。这就是牧马人（监督者）以计算能力为动力的角色以创新的方式获得激励的原因。
例如，如2.3.4所示，牧马人（监督者）可以通过贷款人收取费用 - 不仅监控账户，而且还可以帮助处理要到期的贷款和新贷款。牧马人（监督者）在“清算”帐户时收取赏金。当他触发拍卖时，他也有权获得保证金交易者的抵押品或其交易头寸。
2.4.2. Triggering an Auction 触发拍卖
牧马人（监督者）一旦确认了某个保证金账户需要终止，则会赢得了该保证金账户附加的奖金。然而，在这种状况下还存在一定的风险。牧马人（监督者）不能获得抵押的代币或者对保证金账户的持仓进行清算， 只有保证金账户有权进行操作。 因此监督者需要启动一个竞争拍卖拍卖过程。该过程需得到Lendroid 智能合约系统确认，以及其他监督者的确认，并通过独立的市场信息来对索赔进行审查。 详细的拍卖过程将在后面的一节中描述。
（备注：此处翻译语句不通畅，请大神帮忙修改）
白皮书地址：https://www.lendroid.com/
Lola
区块链研习社精英群成员
2018.02.04 今日立春
祝福一切重生的，迭代的，归零的，新纪元开始了，我看到了你们与我一起，都在路上.......
--------------------------------------------------------------------------------
网友评论