Image Description


Zhidu Inc.





  1. 越狱hook
  2. 网络抓包 篡改


func emailVerfication(disposeBag: DisposeBag) -> Observable<String?> {

    let vCodeBehaviorSubject = BehaviorSubject<String?>(value: nil)

    let pattern = "^[\\w._%+-|][email protected][\\w0-9.-]+\\.[A-Za-z]{2,}$"

    let textObservable = rx.text.distinctUntilChanged().filterNil()

    textObservable.filter { text in text.count <= 0 }.map { _ in "邮箱不可为空" }.bind(to: vCodeBehaviorSubject).disposed(by: disposeBag)
    textObservable.filter { text in text.count > 0 }.map { Validator.regex(pattern).apply($0) ? nil : "邮箱格式不正确" }.bind(to: vCodeBehaviorSubject).disposed(by: disposeBag)

    return vCodeBehaviorSubject






Abstract: Using a cryptographic hash function not as a proof of work by itself, but rather as a generator of pointers to a shared data set, allows for an I/O bound proof of work. This method of proof of work is dif icult to optimize via ASIC design, and dif icult to outsource to nodes without the full data set. The name is based on the three operations which comprise the algorithm: hash, shift, and modulo.


This paper describes a new replication algorithm that is able to tolerate Byzantine faults. We believe that Byzantinefault-tolerant algorithms will be increasingly important in the future because malicious attacks and software errors are increasingly common and can cause faulty nodes to exhibit arbitrary behavior. Whereas previous algorithms assumed a synchronous system or were too slow to be used in practice, the algorithm described in this paper is practical: it works in asynchronous environments like the Internet and incorporates several important optimizations that improve the response time of previous algorithms by more than an order of magnitude. We implemented a Byzantine-fault-tolerant NFS service using our algorithm and measured its performance. The results show that ourservice is only 3% slower than a standard unreplicated NFS.

最近在学习 paxos。英文能力略残,所以把论文按照规则排版之后,在网页上进行 谷歌翻译。


It is well known that fault-tolerance on commodity hardware can be achieved through replication [17, 18]. A common approach is to use a consensus algorithm [7] to ensure that all replicas are mutually consistent [8, 14, 17]. By repeatedly applying such an algorithm on a sequence of input values, it is possible to build an identical log of values on each replica. If the values are operations on some data structure, application of the same log on all replicas may be used to arrive at mutually consistent data structures on all replicas. For instance, if the log contains a sequence of database operations, and if the same sequence of operations is applied to the (local) database on each replica, eventually all replicas will end up with the same database content (provided that they all started with the same initial database state).

最近在学习 paxos。英文能力略残,所以把论文按照规则排版之后,在网页上进行 谷歌翻译。


The Paxos algorithm for implementing a fault-tolerant distributed system has been regarded as difficult to understand, perhaps because the original presentation was Greek to many readers [5]. In fact, it is among the simplest and most obvious of distributed algorithms. At its heart is a consensus algorithm—the “synod” algorithm of [5]. The next section shows that this consensus algorithm follows almost unavoidably from the properties we want it to satisfy. The last section explains the complete Paxos algorithm, which is obtained by the straightforward application of consensus to the state machine approach for building a distributed system—an approach that should be well-known, since it is the subject of what is probably the most often-cited article on the theory of distributed systems [4].